On Mon, Jul 30, 2012 at 09:29:01AM -0500, 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. > > > 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.
The only thing I can add here is perhaps we could use scatter-gather lists of pages instead of large framebuffer. When just passing commands from guest->host->client this would mean guests constructs list -> host reads from list to socket -> client unchanged. For rendering locally on the host (client wants a screenshot, host wants a screenshot) this would be a lot of work, basically having a non linear framebuffer version of pixman. The upside is that you don't need to modify virtio and can use guest ram. > > > 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 >