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 13:08 +0300, Avi Kivity wrote:
>  
> > So we end up with what is effectively a BE framebuffer thanks to qemu
> > hard coding what it thinks the guest endian is (btw, this is quite
> > busted in theory as well since PPC can be bi-endian for example).
> > 
> > Anyways, it works today, it's just that the HW model is wrong... and I
> > don't want to fix it. Any objection ?
> > 
> 
> Yes.  If a correct guest comes along and tries to use cirrus, it will break.

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.

> > 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 :-(

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

Note that in the long run, I don't think cirrus should have much future
for us (ppc) anyway. I'm working on some simple improvements to qemu-vga
to give it basic 2D accel and the corresponding kernel drivers which
should give us overall better functionality than cirrus with simpler &
more maintainable code, along possibly with a virtio tunnel if we want
to pipe spice or similar through without using the virtio-serial
crackpot :-)

Cheers,
Ben.