On 15 September 2013 22:07, Michael S. Tsirkin <m...@redhat.com> wrote: > On Sun, Sep 15, 2013 at 09:40:37PM +0100, Peter Maydell wrote: >> "native" means "if the device's MMIO callback does 'return 0x12345678;' >> for a 32 bit read then the guest CPU should see 0x12345678". That's >> almost always what you want for simple devices (which may in fact >> only support 32 bit accesses to registers), because it means you don't >> have to fill your device with explicit endianness swaps. > > But this means that you device behaves differently > depending on the endian-ness of the guest system. > So it only makes sense if the device is very > system specific
If you mark a device as specifically DEVICE_LITTLE_ENDIAN or DEVICE_BIG_ENDIAN this is *also* very system specific. So you're a bit stuck either way. As I say, for basic "this just provides a bunch of registers" devices _NATIVE_ is the pragmatic answer, since it effectively models the way that the same bit of hardware is wired up to the bus differently if it's expected to be in a big or little endian system. (Any device where you can make byte accesses into the "middle" of a 32 bit register probably needs to think more carefully, but those are pretty rare.) >anything outside hw/<specific architecture> > is at least in theory not a system specific device This is wrong, by the way. hw/$arch contains: * board models * things we haven't properly separated out into self contained devices * random "not actually a device" things like boot code Anything that's really a device goes in its appropriate subdirectory (char, video, etc etc), whether it happens to be used only on one system or one architecture or not. (For instance all the interrupt controllers live in hw/intc though obviously they're hopelessly system specific.) -- PMM
