qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Avi Kivity
Subject: Re: [Qemu-devel] Cirrus bugs vs endian: how two bugs cancel each other out
Date: Mon, 30 Jul 2012 13:08:10 +0300
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:13.0) Gecko/20120615 Thunderbird/13.0.1

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





reply via email to

[Prev in Thread] Current Thread [Next in Thread]