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

[Anthony Liguori]

Avi Kivity <address@hidden> writes:

> On 07/30/2012 05:29 PM, 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.
>
> 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