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. > 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. > 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. For non-virtio-pci versions of the device, the legacy I/O area would not exist. > so the pc-oriented card will have to be a mix of > virtio and stdvga multiplexed on one pci card (maybe two functions, but > I'd rather avoid that). Yes. We could modify stdvga to expose the VGA ram area as the second bar and make the first bar a virtio-pci compatible area. This would require modifying the VGA bios to understand the change but otherwise, should be compatible. It would take modeling VGACommonState as a proper device and then it's a pretty simple process of embedding a VGACommonState within a virtio-pci device. It should work fairly well. It gets a little complicated in terms of who owns the DisplayState but that's a solvable problem. Regards, Anthony Liguori > > -- > error compiling committee.c: too many arguments to function
