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