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

[Benjamin Herrenschmidt <benh@kernel.crashing.org>]

So I got cirrus working on ppc with cirrusdrmfb...

The fun part is that it works :-)

Basically, the issue is that normally, for it to work, one would have to
access the framebuffer using the appropriate aperture for byteswapping
based on the bpp.

However, qemu doesn't emulate those apertures ... and cirrusdrmfb
either.

In fact, qemu cirrus model is just dumb and assumes guest native
byteorder for the framebuffer.

The good thing is that this makes it work... the bad thing is that it's
a completely incorrect HW model and if the linux driver wasn't also
buggy it wouldn't work.

However it's also pretty much unfixable without making it also unusable
in terms of performance so I want to check with you guys if it's ok to
just leave it as-is.

Basically, if the fb was LE as it's supposed to be, one would have to
use the byteswapped apertures. But those can only be emulated by
trapping on every access to turn it into MMIO emulation, which means
unusable performances.

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 ?

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.

Cheers,
Ben.