From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:37858) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SvoYZ-0005ZE-Jx for qemu-devel@nongnu.org; Mon, 30 Jul 2012 07:54:49 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SvoYR-0000Sx-HJ for qemu-devel@nongnu.org; Mon, 30 Jul 2012 07:54:39 -0400 Received: from gate.crashing.org ([63.228.1.57]:34221) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SvoYR-0000Se-8d for qemu-devel@nongnu.org; Mon, 30 Jul 2012 07:54:31 -0400 Message-ID: <1343649267.21647.44.camel@pasglop> From: Benjamin Herrenschmidt Date: Mon, 30 Jul 2012 21:54:27 +1000 In-Reply-To: <50166F2A.1040507@redhat.com> References: <1343629462.21647.32.camel@pasglop> <50165D0A.6060608@redhat.com> <1343647217.21647.40.camel@pasglop> <50166F2A.1040507@redhat.com> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit Mime-Version: 1.0 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: Avi Kivity Cc: qemu-devel@nongnu.org On Mon, 2012-07-30 at 14:25 +0300, Avi Kivity wrote: > > 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. Well, that's what we do today it seems :-) But yes, it would be nice to fix it, the problem is that the fix doesn't seem to be possible while keeping a usable cirrus with KVM on big endian, at least as far as I have investigated so far. > >> > 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. Well, qxl is pretty awful from what I can see so far. I'm more tempted to continue improving qemu-vga, adding a virtio transport, and maybe adding a way to tunnel spice into it if that makes sense but so far, that's stuff was designed for Windows as far as I can tell and is pretty horrible whatever way you look at it... Cheers, Ben.