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
