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

[Benjamin Herrenschmidt <benh@kernel.crashing.org>]

On Mon, 2012-07-30 at 18:24 +0200, Alon Levy wrote:
> On Mon, Jul 30, 2012 at 10:08:07PM +1000, 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 :-)
> > 
> > Why so much effort into a bad design on top of a crack transport btw ?
> Could you elaborate about the design and transport issues that you see?

So Anthony listed a few, the transport being inconsistent with all our
other paravirt model is also part of the problem, and the spice code
base just hurts my eyes. The fact that it's essentially GDI centric
makes it a non starter for me anyway.

> > Is it just RH politics of there's a good reason hiding somewhere ? Some
> No politics AFAIK. Spice code may suck but it's doing a good job while
> sucking, so we prefer to fix it unless a good design that makes it
> easier to rebuild from scratch comes along. I'm all ears.
> 
> > kind of morbid fascination for anything Windows ?
> We do have bad linux performance but the is work going to improve it, by
> adding RENDER implementation to our driver and protocol additions, among
> others.

Which still makes me feel like we should be doing something better
targeted at Linux exclusively.

> > 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.
> > 
> > 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.
> 
> I'll be happy to elaborate on any part of qxl/spice that I understand
> and help you help us improve it.

Well, the main thing to begin with from my perspective would be to make
it work on powerpc, and thus handle all the endianness issues etc... but
at this stage, it seems pretty far out.

Cheers,
Ben.