From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:33245) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Svmth-0004mz-R5 for qemu-devel@nongnu.org; Mon, 30 Jul 2012 06:08:27 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Svmtb-0002Qk-Rw for qemu-devel@nongnu.org; Mon, 30 Jul 2012 06:08:21 -0400 Received: from mx1.redhat.com ([209.132.183.28]:27271) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Svmtb-0002Qe-K7 for qemu-devel@nongnu.org; Mon, 30 Jul 2012 06:08:15 -0400 Message-ID: <50165D0A.6060608@redhat.com> Date: Mon, 30 Jul 2012 13:08:10 +0300 From: Avi Kivity MIME-Version: 1.0 References: <1343629462.21647.32.camel@pasglop> In-Reply-To: <1343629462.21647.32.camel@pasglop> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] Cirrus bugs vs endian: how two bugs cancel each other out List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Benjamin Herrenschmidt Cc: qemu-devel@nongnu.org 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