Avi Kivity <a...@redhat.com> writes: > On 07/30/2012 05:29 PM, Anthony Liguori wrote: >> Avi Kivity <a...@redhat.com> writes: >> >>>>> Virtio makes sense for qxl, but for now we have the original pci model >>>>> which I don't see a reason why it can't work for ppc. >>>> >>>> I'm sure it can work for PPC given enough effort. But I think the >>>> question becomes, why not invest that effort in moving qxl to the >>>> standard transport that the rest of our PV devices use. >>> >>> The drm drivers for the current model are needed anyway; so moving to >>> virtio is extra effort, not an alternative. >> >> This is just a point in time statement. If we were serious about using >> virtio then we could quickly introduce a virtio transport and only >> target the DRM drivers at the virtio transport. > > That doesn't help all the deployed hypervisors out there. IMO we're > mature enough, and the difference doesn't warrant a new interface.
QXL has a lot of short comings. Here's a short list: - It's 100% PC centric. It requires PCI and is completely oblivious to endianness. - It's all-or-nothing with respect to Spice support. libspice is a big external dependency. It cannot be mandated as a QEMU requirement because it's not portable enough. This means we can never make qxl the default device because we can't guarantee it's there. - There's no obvious way to map to non-PCI systems (either S390 or embedded platforms). I'm not saying that we should remove qxl.c from QEMU. We can continue to support that ABI forever. But there's a lot of value in a new graphics interface that uses virtio and negotiates support for the Spice protocol. That way, if QEMU doesn't have Spice support, the feature won't be exposed to the guest and you can still have a legacy VGA interface. Then we can change the default. Basic 2d commands (like blit and solid fill) can be done without going through libspice. Then we can stop messing around with having multiple display types. It would be a huge usability improvement and would allow us to focus on a single graphics adapter for all architectures. > >>> Note virtio doesn't support mapping framebuffers yet >> >> Yes. I haven't seen a good proposal yet on how to handle this. I think >> this is the main problem to solve. > > It doesn't seem to be such a huge problem, though it does turn virtio > into a respec'ed PCI. Virtio was originally designed to be a DMA API (although not ABI). From a virtio-pci perspective, adding a large memory area that can be referenced is not a big deal at all. You can take PFNs into the memory area and just handle it like you would any other address reference. But for the virtio API within Linux, it presents a challenge. Originally, there was a desire to support DMA-based interfaces like Xen's grant tables or PowerVM's TCE transfers. While there have been proof of concepts, it's never landed in an upstream kernel. I'd be perfectly happy forcing the virtio API to assume the ability to share large areas of memory between the host and guest and eliminate the possibility to support all types of hypervisors for some devices. (While Xen supports shared memory, PowerVM does not--I don't give a damn about supporting PowerVM FWIW). Rusty, what do you think about the above? Regards, Anthony Liguori > >> >>> or the entire vga compatibility stuff >> >> This is actually independent of virtio. A virtio-pci device could >> expose it's class code as a VGA adapter and also handle I/O accesses for >> the legacy region. This is strictly a PC-ism. > > We have to share the BAR space with VGA; not a huge problem. > > > -- > error compiling committee.c: too many arguments to function