Re: [Qemu-devel] Cirrus bugs vs endian: how two bugs cancel each other out

[Alon Levy]

On Mon, Jul 30, 2012 at 09:29:01AM -0500, Anthony Liguori wrote:
> Avi Kivity <address@hidden> 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
>