On 07/30/2012 09:24 AM, Benjamin Herrenschmidt wrote: > 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 ? >
Yes. If a correct guest comes along and tries to use cirrus, it will break. > 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? 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? -- error compiling committee.c: too many arguments to function
