On Mon, 2014-06-16 at 20:30 +1000, Benjamin Herrenschmidt wrote: > Hi ! > > So while trying to solve an issue we have with qemu/kvm and powerpc who > can be both LE and BE nowadays, we thought the ideal solution would be > to have a register in the emulated VGA to control the endian.
No reply ... anybody out there ? :-) (Responding with a different email address as I've had issues with gmail over eager spam filtering lately). So basically, I want to define VBE register 0xb as "endian control" which may or may not be supported by a given platform. The problem is how to expose to the OS that it exists (or doesn't) ? Because if we just add it to qemu and make Linux start poking at it (including on x86), then things will break when running Linux under Bochs as it will hit a BX_PANIC when we access a VBE register it doesn't know about. My proposal is thus to add a backward compatible way to check for that support before accessing it (and of course define the register number in bochs so that this same number doesn't get reused later for other purposes). One simple option that will probably work is to add stuff to the existing "GET_CAPABILITIES" mode. When that is selected, we could for example make the "BANK" register return additional capability flags, one of them being "endian support". This gives us a way to add more extensions later on if needed as well. Another option would be to use an unused bit if the ENABLE register and simply force it to 1 on reads when the endian control register is present... though in this case it might be a better idea to use that bit to indicate the presence of "extended flags", use a new register 0xb as "EXTENDED_FLAGS", and use a flag in there as indicative of the presence of endian control which becomes register 0xc. That way you also have room for more extensions if you wish to do so in the future. Any opinion ? I'm happy to make & submit the patches, I just want an agreement on the approach first. Cheers, Ben. > Since qemu wishes to remain as much as possible in sync / compatible > with Bochs, I'm posting to this list so that the definition can be > made common even if Bochs doesn't have to actually implement it. > > Now the basic idea is to have a bit indicating that endian control is > supported and a bit to control the guest endianness, set by the guest > appropriately (which affects all the pixel formats). > > My original idea was to add a VBE register. However BOCHS seems to > be unhappy (after a quick glance at the source) if the guest tries to > read a non-existing register, so I suppose either the "support endian > switch" information needs to be encoded in an existing register in a way > that doesn't break existing code ... or the presence of the new register > advertised in such a way, for example via the PCI revision ID. > > Note that I am not trying to support something like endian apertures and > that whole trainwreck that we had back in the day on BE machines. Simply > carry the guest endianness assuming that this affects all the pixel > formats which continue to be the classic ARGB ones, simply encoded with > the right endian (so 8bpp is unaffected for example). > > Any suggestion ? Comment ? Flame ? :-) > > Cheers, > Ben. >
