On Mon, Jul 30, 2012 at 09:54:27PM +1000, Benjamin Herrenschmidt wrote: > 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
I would love to hear something more specific about this. I assume you are talking about libspice-server and not the device itself, since the device itself has nothing specifically matching windows. > 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. > > >
