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

[Anthony Liguori]

Gerd Hoffmann <address@hidden> writes:

>   Hi,
>
>> 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.
>
> No.  The endianess is actually clearly defined.  It's little endian for
> both guest/host interface (aka qxl) and the network protocol.

Right, because it was designed without regard to endianness and then
declared as little endian since it was written that's what x86 happens
to be :-)

One of the nice properties of virtio is that the ring is defined to be
in guest-endian.  This does make access a bit faster.

> So it is "only" the libspice code which needs fixing.  Should be not as
> bad as it sounds.  There is a code generator for writing/parsing the
> network protocol, winding up native endian <=> little endian handling
> there shouldn't be that hard.  Likewise there is a piece of code
> translating qxl device structs into internal spice-server structs
> (applying sanity checks along the way).  There we can hook up the
> byteswapping for the guest/host interface.

I have no doubt that it's fixable and ought to be fixed.

>
>> - 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.
>
> Indeed.
>
>> 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.
>
> What does it buy us?

A single guest driver/configuration that works whether or not libspice
is available on the host.

A single graphics driver configuration which means that users can stop
worry about what graphics card type is specified.

> Even with -vga std-which-might-have-spice-over-virtio-support you still
> have to figure whenever qemu has spice support and pass / don't pass
> -spice $opts accordingly.

If you want to configure a Spice server, yes.  If you're just doing
local graphics, it shouldn't matter, right?

>> Then we can change the default.  Basic 2d commands (like blit and solid
>> fill) can be done without going through libspice.
>
> We can create a set of basic 2d accel commands and implement them in
> both stdvga and qxl, where qxl would translate them into spice ops of
> course.
>
>> 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.
>
> Improving stdvga to support basic 2d accel isn't that much effort.  I
> think it is worth doing it, even when it is obsoleted by a redesigned /
> rewritten qxl2 some day.

I think we're pretty much in agreement here.  I think if we improve
stdvga by making it a virtio device, then it becomes pretty easy to
eventually make it qxl2.

Regards,

Anthony Liguori

>
> cheers,
>   Gerd