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

[Anthony Liguori]

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.

> 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