Re: [Qemu-devel] Implementing qxl-virtio on QEMU

[Gerd Hoffmann]

On 08/27/12 08:08, Gerd Hoffmann wrote:
> On 08/24/12 21:14, Erlon Cruz wrote:
>> The following patches makes provides video support to non PCI architectures, 
>> please review!
> 
> Can you give an overview on the virtio-qxl virtual hardware design?

Self-reply-ing.  There is a paper on it (got link @ irc):

http://www.rachacuca.org/~fidencio/VirtioQXL%20-%20a%20virtio%20video%20device%20for%20para%20virtualized%20KVM%20guests.pdf

Well.  The design is *way* too close to the original, non-virtio qxl
device.  The reason is code reuse according to the paper.  I think it
would be *much* better to just take a fresh start.  Reasons:

First the qxl device carries a bunch of legacy stuff for compatibility
with old guests & guest drivers.  When designing a new device I'd like
to throw away as much as possible of this stuff.

Second you'll need a kernel driver to drive the virtio queues.  The
linux graphics world is moving to kernel drivers (aka kms) anyway, so
this shouldn't be a big issue.  You'll also get a framebuffer console
then, so you can see the linux boot messages quite early.  That is a
nice thing, especially without vga compatibility.

More hints:

On memory management:  spice does *not* require device memory.  spice
has "memory slots".  They are a thin layer to allow the spice server
library dereference pointers in qxl commands.  qxl allows guests to
register memory slots for the qxl device memory.  That is a qxl
restriction though, not a spice restriction.  Letting the virtio-qxl kms
driver allocate a big memory block at boot, then register that as memory
slot and store qxl commands, cmd data + surfaces there is no problem,
spice server can handle that just fine.  No copying needed.
You could also setup memory slot(s) for *all* guest ram, then kmalloc()
memory as needed.

Don't use spice rings at all.  Use virtio rings instead.  I think we
need these:

  (1) spice rendering commands (replaces QXLCommandRing).
  (2) spice cursor commands (replaces QXLCursorRing).
  (3) resource release (replaces QXLReleaseRing).
  (4) device setup ring (replace QXL_IO_*).
  (5) device event ring (spice server notifications go here,
                         replacing QXL_INTERRUPT_*).

Don't use QXLRom.  The mode table in qxlrom is historical baggage anyway
and should be dropped.  Most of the other stuff is related to the qxl
device too and can be dropped.  Anything remaining can be queried by the
guest using a virtio request on the device setup ring.

Don't use QXLRam.  Arguments for QXL_IO_* ops are there, this can be
stuffed into the virtio request buffer instead.

cheers,
  Gerd