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

[Alon Levy <alevy@redhat.com>]

On Tue, Jul 31, 2012 at 08:24:23AM +1000, Benjamin Herrenschmidt wrote:
> 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.

Using virtio - +1 - I'm not actively working on it because of priorities
issues, but if it comes along I'll be happy to help making it work as
well as the existing device.

There is really not much different between virtio + linear framebuffer
and the qxl pci device, so I really don't see a lot of issues in
porting.

But other then this issue, I'm not sure what you think is windows
specific: The protocol is not the transport. GDI over a wire is
accurate, but adding RENDER makes it X over the wire (the wire here
being both qxl/future-virtio and the tcp spice protocol). And for the
future we will be passing bo's and TGSI command streams probably to the
host, rendering it and pushing video to the client. But that's still a
way off. Nothing window's specific there either (except the driver part
of course).

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

I'm sure we can make spice endianess clean. If you look at how it works,
server/red_parse.c reads from the device (so this is the single point to
change if the transport moves from QXLPHYSICAL meaning a encoded
slot/offset into a BAR to some other location identifier like a handle
when using virtio) and writes to spice specific structs, which are then,
like Anthony pointed out, stored in a tree for dropping operations that
have become obsolete before being sent to the client, and also put on a
pipe (queue) of messages to be sent to the client.

That would be the place to do any endianess convertions between guest
and host. The network protocol is LE (yes, counter to the norm, I know.
It is possible to add a capability to spice to change this though if we
really want. So only the initial handshake would have to be LE and the
rest would be BE).

> 
> Cheers,
> Ben.
> 
>