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

[Alon Levy <alevy@redhat.com>]

On Mon, Jul 30, 2012 at 09:54:27PM +1000, Benjamin Herrenschmidt wrote:
> On Mon, 2012-07-30 at 14:25 +0300, Avi Kivity wrote:
> 
> > > Right. Cirrus on ppc was used on PReP and Amiga for example though not
> > > many people really care about those platforms anymore. I'm not too
> > > worried at this point with that possibility but we shall know about it.
> > 
> > Emulating something incorrectly on purpose is wrong.  Use qxl or stdvga
> > (you can make either the default for ppc), but don't break cirrus or
> > rely on it being broken.
> 
> Well, that's what we do today it seems :-) But yes, it would be nice to
> fix it, the problem is that the fix doesn't seem to be possible while
> keeping a usable cirrus with KVM on big endian, at least as far as I
> have investigated so far.
> 
> > >> > As for the work I'm doing to brush up pci-vga a bit, I'm tempted to add
> > >> > an MMIO reg or a VBE config reg bit to allow configuring the endianness
> > >> > of the underlying fb with a default to what qemu does today.
> > >> 
> > >> What are those byteswapped apertures?  Some chipset thing that does the
> > >> byteswap?
> > > 
> > > The card itself. The 16M BAR is divided in 4 "apertures" (at least some
> > > Cirrus models do that including the one we emulate by default). One is
> > > no byteswap, two are 16-bit and 32-bit byteswap and the last one uses a
> > > specific byteswap for video overlay which I haven't looked at in detail.
> > > 
> > >> IIRC ppc has a bit in the TLB entry that tells it to byteswap.  Can't we
> > >> use it directly map the framebuffer with byteswapping?
> > > 
> > > Unfortunately only embedded ppc's have that :-(
> > 
> > Too bad :(
> > 
> > > 
> > > We can also make the fbdev/fbcon driver do the swapping in SW, but it's
> > > a relatively unusual code path and I don't think it works properly with
> > > X, I don't think it can be made to work properly with the generic X KMS
> > > at this point.
> > > 
> > > Now, cirrusdrmfb is already specific to the qemu cirrus variant in
> > > several ways, I wouldn't mind keeping it that way and if we "fix" the
> > > endianness model, maybe having a "hidden" register to flip it back to
> > > it's current mode of operation that cirrusdrmfb would use...
> > 
> > That's possible, but why not go all the way to qxl?
> >
> > That will give you better graphics performance with no need to hack.
> 
> Well, qxl is pretty awful from what I can see so far. I'm more tempted

I would love to hear something more specific about this. I assume you
are talking about libspice-server and not the device itself, since the
device itself has nothing specifically matching windows.

> to continue improving qemu-vga, adding a virtio transport, and maybe
> adding a way to tunnel spice into it if that makes sense but so far,
> that's stuff was designed for Windows as far as I can tell and is pretty
> horrible whatever way you look at it...
> 
> Cheers,
> Ben.
> 
> 
>