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

[Avi Kivity <avi@redhat.com>]

On 07/30/2012 02:20 PM, Benjamin Herrenschmidt wrote:
> 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.

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.

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

-- 
error compiling committee.c: too many arguments to function