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

[Gerd Hoffmann]

On 07/30/12 14:08, Benjamin Herrenschmidt wrote:
> On Mon, 2012-07-30 at 14:58 +0300, Avi Kivity wrote:
>> Let's balkanize some more then?
>>
>> No, qxl is our paravirt vga, we should improve it instead of spawning
>> new ones (which will be horrible in the eyes of the next person to look
>> at them).  You should also be getting the drm driver for free.
>>
>> http://spice-space.org/page/DRM
> 
> "Free" is a big word here, I wouldn't be surprised if it was totally
> endian busted :-)

Well, not totally.  But it used to be, and although a bunch of cleanup &
fixing happened already I doubt spice will run out-of-the-box on
bigendian machines.

> People I've talked to around in the community seem to agree that some
> minor improvements on qemu-vga are worthwhile, so I'm doing them,
> nothing drastic, mostly having a mirror of the legacy IO registers in an
> MMIO BAR so it's more usable for non-x86 platforms, and I'm about to add
> some simplistic 2D blit facility so we can have a semi-decent fb console
> over vnc. I can trivially do an equivalent of cirrusdrmfb for it so we
> get X mode setting / RandR.
> 
> That gives us a baseline for mostly unaccelerated 2D.

Makes sense.

> Something tells me that getting that spice/qxl gunk will be more than a
> trivial effort (but I might be wrong) and I'm reluctant to start
> committing effort on it since so far I yet have to see it being actually
> picked up by people.

For a decent paravirt gfx card (supporting more than just basic X11 &
fbcon with scroll-bitblit) going qxl makes more sense.  Oh, and most of
the endian issues in the spice code base are *not* in hw/qxl*.[ch], but
in the spice-server library and spice client code.  So plumbing in
spice-over-virtio into stdvga doesn't buy you much ...

cheers,
  Gerd