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.