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

[Gerd Hoffmann <kraxel@redhat.com>]

  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.

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.

> - 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?

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.

> 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.

cheers,
  Gerd