Re: [Qemu-devel] [Qemu-ppc] [PATCH v3 11/14] ioport: Switch dispatching to memory core layer
Peter Maydell peter.mayd...@linaro.org writes: On 12 July 2013 23:50, Benjamin Herrenschmidt b...@kernel.crashing.org wrote: Our experience is that it actually works fine for almost everything except virtio :-) ie mostly TARGET_WORDS_BIGENDIAN is irrelevant (and should be). I agree that TARGET_WORDS_BIGENDIAN *should* go away, but it exists currently. Do you actually implement a CPU which does dynamic endianness flipping? TCG already supports bi-endianness for PPC. Grep for 'le_mode' in target-ppc/translate.c to see how the TCG instruction stream is affected by it. On PPC, le_mode only really affects load/stores and instruction decoding. Any shared data structures between the CPU and OS remain big endian. So TARGET_WORDS_BIGENDIAN is still accurate even when le_mode=1. It's not the semantic equivalent of changing TARGET_WORDS. Regards, Anthony Liguori Is it at all efficient in the config which is the opposite of whatever TARGET_WORDS_BIGENDIAN says? thanks -- PMM
Re: [Qemu-devel] [Qemu-ppc] [PATCH v3 11/14] ioport: Switch dispatching to memory core layer
On 15 July 2013 15:01, Anthony Liguori anth...@codemonkey.ws wrote: Peter Maydell peter.mayd...@linaro.org writes: On 12 July 2013 23:50, Benjamin Herrenschmidt b...@kernel.crashing.org wrote: I agree that TARGET_WORDS_BIGENDIAN *should* go away, but it exists currently. Do you actually implement a CPU which does dynamic endianness flipping? TCG already supports bi-endianness for PPC. Grep for 'le_mode' in target-ppc/translate.c to see how the TCG instruction stream is affected by it. Right, that's what I thought. This means that if you're on a little-endian host and using a PPC chip in le-mode then the QEMU infrastructure will byteswap the data, and then those generated bswap* ops will byteswap it again. It would be more efficient if we supported dynamically having the emulated CPU specify whether it wanted a BE or LE memory access, and then byteswapping the correct number of times based on device/host endianness/CPU setting. (This would also avoid ugliness like the current ARM BE8 code which should be doing BE read for data, LE read for instructions and instead has to do BE read of everything via TARGET_WORDS_BIGENDIAN and then swap the instruction words again to get back to LE.) If we ever want to support multiple different CPUs in one model we'll need this anyway, because one might be BE and another LE. On PPC, le_mode only really affects load/stores and instruction decoding. Any shared data structures between the CPU and OS remain big endian. So TARGET_WORDS_BIGENDIAN is still accurate even when le_mode=1. It's not the semantic equivalent of changing TARGET_WORDS. I'm not sure what you mean by accurate here. It's a compile time switch, when the hardware we're actually emulating does runtime (dynamic) switching, and when the current runtime mode doesn't match the compiled-in setting we end up doing unnecessary double-swap operations. thanks -- PMM
Re: [Qemu-devel] [Qemu-ppc] [PATCH v3 11/14] ioport: Switch dispatching to memory core layer
On Mon, 2013-07-15 at 09:01 -0500, Anthony Liguori wrote: On PPC, le_mode only really affects load/stores and instruction decoding. Any shared data structures between the CPU and OS remain big endian. Translation: On ppc with the specific machine type pseries which emulates a paravirtualized environment, the data structures between the guest and the hypervisor remain big endian :-) But this is essentially irrelevant to the basic discussion about endian handling (ie. PCI devices remain LE, etc...). Point is, TCG can deal with dual endian reasonably easily. The main issues are around things like virtio with its stupid concept of guest endian (wtf does guest endian means on a dual endian processor ?) but I think we've whacked Rusty's head plenty enough on that one... and it's not that hard to work around. So TARGET_WORDS_BIGENDIAN is still accurate even when le_mode=1. It's not the semantic equivalent of changing TARGET_WORDS. The point is that it's unnecessary :-) IE. We should aim to get rid of the concept of target endianness altogether :-) Cheers, Ben.
Re: [Qemu-devel] [Qemu-ppc] [PATCH v3 11/14] ioport: Switch dispatching to memory core layer
On Fri, 2013-07-12 at 05:18 +0200, Alexander Graf wrote: We model a single system wide io space today and access to that one happens through you pci host controller. I just messed up the terminology here. Single system wide IO space is broken. We have separate IO space per PHB. That was working afaik. In any case, I completely object to all that business with conversion in bridges. That's fundamentally WRONG. The whole business of endianness in qemu is a mess. In the end what matters and the only thing that does is: * The endianness of a given memory access by the guest (which may or may not be the endianness of the guest - MSR:LE, byteswap load/store instsructions, etc..) vs. * The endianness of the target device register (and I say register ... a framebuffer does NOT have endianness per-se and thus accesses to BAR mapping a memory range (framebuffer, ROM, ...) should go such that the *byte order* of individual bytes is preserved, which typically means untranslated). Unless they are completely broken (and those exist, don't get me wrong, though mostly they are a thing of a past long gone), bridges and busses have no effect on endianness. So I'm not sure what you guys are up to, but from what I read, it's wrong, and the fact at this stage is that your broke IO space (and thus virtio and VGA) on powerpc (including pseries). Cheers, Ben.
Re: [Qemu-devel] [Qemu-ppc] [PATCH v3 11/14] ioport: Switch dispatching to memory core layer
Benjamin Herrenschmidt a écrit : On Fri, 2013-07-12 at 05:18 +0200, Alexander Graf wrote: We model a single system wide io space today and access to that one happens through you pci host controller. I just messed up the terminology here. Single system wide IO space is broken. We have separate IO space per PHB. That was working afaik. In any case, I completely object to all that business with conversion in bridges. That's fundamentally WRONG. Indeed. The whole business of endianness in qemu is a mess. In the end what matters and the only thing that does is: * The endianness of a given memory access by the guest (which may or may not be the endianness of the guest - MSR:LE, byteswap load/store instsructions, etc..) On PowerPC PReP, you have the MSR:LE bit in the CPU, and the system endianness (port 0x92 on PReP system I/O board). Of course, both can be changed independently, but they are usually changed within a few instructions. When only one of them is changed, this means some interesting things can happen. For example, in [1]: When PowerPC little-endian is in effect but before system's little-endian is in effect, the address munge becomes effective. If we need to access system endian port (byte) address, say 0x8092, the program needs to issue 0x8095 instead, to compensate (unmunge) for the effect of PowerPC address modification. Those will be required for QEMU to be able to run BeOS, AIX, or Windows NT or PowerPC PReP. In the light of this, I think there should only be one endianness for all memory accesses (which could be changed at runtime), and all bridges/devices should ask for same endianness as parent or reverse endianness as parent, but not for big, little, or native endianness. Regards, Hervé [1] ftp://ftp.software.ibm.com/rs6000/technology/spec/endian.ps)
Re: [Qemu-devel] [Qemu-ppc] [PATCH v3 11/14] ioport: Switch dispatching to memory core layer
Benjamin Herrenschmidt b...@kernel.crashing.org writes: On Fri, 2013-07-12 at 05:18 +0200, Alexander Graf wrote: We model a single system wide io space today and access to that one happens through you pci host controller. I just messed up the terminology here. Single system wide IO space is broken. We have separate IO space per PHB. That was working afaik. Hrm, probably not. We don't propagate I/O spaces very well today. In any case, I completely object to all that business with conversion in bridges. That's fundamentally WRONG. The whole business of endianness in qemu is a mess. In the end what matters and the only thing that does is: It's not as bad as you think I suspect. * The endianness of a given memory access by the guest (which may or may not be the endianness of the guest - MSR:LE, byteswap load/store instsructions, etc..) Correct. vs. * The endianness of the target device register (and I say register ... a framebuffer does NOT have endianness per-se and thus accesses to BAR mapping a memory range (framebuffer, ROM, ...) should go such that the *byte order* of individual bytes is preserved, which typically means untranslated). Yes. To put it another way, an MMIO write is a store and depending on the VCPU, that will result in a write with a certain byte order. That byte order should be preserved. However, what we don't model today, and why we have the silly endianness in MemoryRegionOps, is the fact that I/O may pass through multiple layers and those layers may change byte ordering. We jump through great hoops to have a flat dispatch table. I've never liked it but that's what we do. That means that in cases where a host bridge may do byte swapping, we cannot easily support that. That's really what endianness is for but it's abused. Unless they are completely broken (and those exist, don't get me wrong, though mostly they are a thing of a past long gone), bridges and busses have no effect on endianness. That's simply not true. There are programmable PCI host bridges that support byte swapping. Some allow this to be done on a per-device basis too. So I'm not sure what you guys are up to, but from what I read, it's wrong, and the fact at this stage is that your broke IO space (and thus virtio and VGA) on powerpc (including pseries). I'm not sure what this patch was trying to do but it was certainly wrong. Regards, Anthony Liguori Cheers, Ben.
Re: [Qemu-devel] [Qemu-ppc] [PATCH v3 11/14] ioport: Switch dispatching to memory core layer
On 12 July 2013 18:49, Anthony Liguori anth...@codemonkey.ws wrote: Benjamin Herrenschmidt b...@kernel.crashing.org writes: On Fri, 2013-07-12 at 05:18 +0200, Alexander Graf wrote: We model a single system wide io space today and access to that one happens through you pci host controller. I just messed up the terminology here. Single system wide IO space is broken. We have separate IO space per PHB. That was working afaik. Hrm, probably not. We don't propagate I/O spaces very well today. In any case, I completely object to all that business with conversion in bridges. That's fundamentally WRONG. It's not wrong when the hardware actually does a byteswap at some level in the memory hierarchy. You can see this for instance on ARMv7M systems, where byteswapping for bigendian happens at an intermediate level that not all accesses go through: [CPU] [byteswap here] -- [memory and ext. devices] | -- [internal memory mapped devices] so some things see always little endian regardless. The whole business of endianness in qemu is a mess. In the end what matters and the only thing that does is: It's not as bad as you think I suspect. * The endianness of a given memory access by the guest (which may or may not be the endianness of the guest - MSR:LE, byteswap load/store instsructions, etc..) Correct. vs. * The endianness of the target device register (and I say register ... a framebuffer does NOT have endianness per-se and thus accesses to BAR mapping a memory range (framebuffer, ROM, ...) should go such that the *byte order* of individual bytes is preserved, which typically means untranslated). Yes. To put it another way, an MMIO write is a store and depending on the VCPU, that will result in a write with a certain byte order. That byte order should be preserved. However, what we don't model today, and why we have the silly endianness in MemoryRegionOps, is the fact that I/O may pass through multiple layers and those layers may change byte ordering. We jump through great hoops to have a flat dispatch table. I've never liked it but that's what we do. That means that in cases where a host bridge may do byte swapping, we cannot easily support that. We could support that if we cared to -- you just have to have a container MemoryRegion type which is a byte-swapping container (or just have a flag on existing containers, I suppose). Then as you flatten the regions into the flat table you keep track of how many levels of byteswapping each region goes through, and you end up with a single 'byteswap or not?' flag for each section of your flat dispatch table. (Our other serious endianness problem is that we don't really do very well at supporting a TCG CPU arbitrarily flipping endianness -- TARGET_WORDS_BIGENDIAN is a compile time setting and ideally it should not be.) thanks -- PMM
Re: [Qemu-devel] [Qemu-ppc] [PATCH v3 11/14] ioport: Switch dispatching to memory core layer
Hervé Poussineau hpous...@reactos.org writes: When only one of them is changed, this means some interesting things can happen. For example, in [1]: When PowerPC little-endian is in effect but before system's little-endian is in effect, the address munge becomes effective. If we need to access system endian port (byte) address, say 0x8092, the program needs to issue 0x8095 instead, to compensate (unmunge) for the effect of PowerPC address modification. Those will be required for QEMU to be able to run BeOS, AIX, or Windows NT or PowerPC PReP. In the light of this, I think there should only be one endianness for all memory accesses (which could be changed at runtime), We already do this, it's host native endian. and all bridges/devices should ask for same endianness as parent or reverse endianness as parent, but not for big, little, or native endianness. I/O doesn't propagate so there's no way to say something like this. That's the fundamental problem IMHO. Regards, Anthony Liguori Regards, Hervé [1] ftp://ftp.software.ibm.com/rs6000/technology/spec/endian.ps)
Re: [Qemu-devel] [Qemu-ppc] [PATCH v3 11/14] ioport: Switch dispatching to memory core layer
On Fri, 2013-07-12 at 19:04 +0200, Hervé Poussineau wrote: When PowerPC little-endian is in effect but before system's little-endian is in effect, the address munge becomes effective. If we need to access system endian port (byte) address, say 0x8092, the program needs to issue 0x8095 instead, to compensate (unmunge) for the effect of PowerPC address modification. Those will be required for QEMU to be able to run BeOS, AIX, or Windows NT or PowerPC PReP. Funnily enough we've dropped support for Linux on PReP a long time ago :-) In the light of this, I think there should only be one endianness for all memory accesses (which could be changed at runtime), and all bridges/devices should ask for same endianness as parent or reverse endianness as parent, but not for big, little, or native endianness. Right. I would in fact avoid the term endianness that tends to confuse people and basically stick to this: - For a given access, know (attribute) which byte is first in ascending address order - For a given target *register* (and again, this ONLY applies to registers and in fact, some devices might change their register endianness and also have several banks with a different one), which byte is first in ascending address order. This is at that point that a conversion might need to occur, and only at that point if there is a mismatch. Ben.
Re: [Qemu-devel] [Qemu-ppc] [PATCH v3 11/14] ioport: Switch dispatching to memory core layer
On Fri, 2013-07-12 at 12:49 -0500, Anthony Liguori wrote: Unless they are completely broken (and those exist, don't get me wrong, though mostly they are a thing of a past long gone), bridges and busses have no effect on endianness. That's simply not true. There are programmable PCI host bridges that support byte swapping. Some allow this to be done on a per-device basis too. Those bridges are utterly broken and the result of very sick HW design mind. I've encountered that sort of thing before and the only sane way to use them is to disable that shit. If a bridge swaps, it breaks byte order of non-register accesses (FIFO transfers, DMAs, ...) and hell breaks lose. Unless you confuse with the byte lane swapping that must occur when bridging a processor to a bus when the processor changes its bus byte order. IE. Some processors (generally older, people have grown clues since then) that can support dual endian operations had the bad habit of reversing the location of the low-address and high-address bytes on their bus (or rather didn't properly reverse LSB/MSB and thus requires bridges to do it). Such processors do require the bridge to swap the byte lanes when changing endianness. However I've been told that even ARM doesn't do that any more. In any case, even if you want to model a piece of crap like that, you shouldn't do so by calling the bus big endian or little endian but something like a byte lane swap attribute, which more precisely describes what the bridge is doing. This is not endianness. So I'm not sure what you guys are up to, but from what I read, it's wrong, and the fact at this stage is that your broke IO space (and thus virtio and VGA) on powerpc (including pseries). I'm not sure what this patch was trying to do but it was certainly wrong. Right :-) Ben.
Re: [Qemu-devel] [Qemu-ppc] [PATCH v3 11/14] ioport: Switch dispatching to memory core layer
On Fri, 2013-07-12 at 19:26 +0100, Peter Maydell wrote: It's not wrong when the hardware actually does a byteswap at some level in the memory hierarchy. You can see this for instance on ARMv7M systems, where byteswapping for bigendian happens at an intermediate level that not all accesses go through: [CPU] [byteswap here] -- [memory and ext. devices] | -- [internal memory mapped devices] so some things see always little endian regardless. Ugh ? That's so completely fucked up, if that's indeed what the HW is doing this is a piece of trash and the designers are in urgent need of being turned into fertilizer. Unless again you are talking about lane swapping which allows to preserve the byte address invariance when the CPU decides to flip its bus around, but I would have thought that modern CPUs do not do that sort of shit anymore. In any case, it cannot be represented with an endian attribute at the bridge level, that doesn't mean anything. Again, the only endian attribute that exists are the byte order of the original access (which byte has the lowest address, regardless of significance of those bytes in the target, ie, purely from a qemu standpoint, in the variable that carries the access around inside qemu, which byte has the lowest address), and the same on the target device (at which point a concept of significance does apply, but it's a guest driver business to get it right, qemu just need to make sure byte 0 goes to byte 0). If a bridge flips things around in a way that breaks the model, then add some property describing the flipping properties but don't call it big endian or little endian at the bridge level, that has no meaning, confuses things and introduces breakage like we have seen. The whole business of endianness in qemu is a mess. In the end what matters and the only thing that does is: It's not as bad as you think I suspect. * The endianness of a given memory access by the guest (which may or may not be the endianness of the guest - MSR:LE, byteswap load/store instsructions, etc..) Correct. vs. * The endianness of the target device register (and I say register ... a framebuffer does NOT have endianness per-se and thus accesses to BAR mapping a memory range (framebuffer, ROM, ...) should go such that the *byte order* of individual bytes is preserved, which typically means untranslated). Yes. To put it another way, an MMIO write is a store and depending on the VCPU, that will result in a write with a certain byte order. That byte order should be preserved. However, what we don't model today, and why we have the silly endianness in MemoryRegionOps, is the fact that I/O may pass through multiple layers and those layers may change byte ordering. We jump through great hoops to have a flat dispatch table. I've never liked it but that's what we do. That means that in cases where a host bridge may do byte swapping, we cannot easily support that. We could support that if we cared to -- you just have to have a container MemoryRegion type which is a byte-swapping container (or just have a flag on existing containers, I suppose). Then as you flatten the regions into the flat table you keep track of how many levels of byteswapping each region goes through, and you end up with a single 'byteswap or not?' flag for each section of your flat dispatch table. (Our other serious endianness problem is that we don't really do very well at supporting a TCG CPU arbitrarily flipping endianness -- TARGET_WORDS_BIGENDIAN is a compile time setting and ideally it should not be.) Our experience is that it actually works fine for almost everything except virtio :-) ie mostly TARGET_WORDS_BIGENDIAN is irrelevant (and should be). Cheers, Ben.
Re: [Qemu-devel] [Qemu-ppc] [PATCH v3 11/14] ioport: Switch dispatching to memory core layer
On Fri, 2013-07-12 at 14:06 -0500, Anthony Liguori wrote: In the light of this, I think there should only be one endianness for all memory accesses (which could be changed at runtime), We already do this, it's host native endian. The simple fact that you used the word endian makes it broken here :-) If the guest has done a byte reverse access for example, what you have is not host native endian anymore. The simple fact that you use endian to describe what you carry around is a source of wrongness and errors. It's misleading and people always get that wrong (I did a bloody talk on the matter at two conferences now and it seems people really don't get what endianness really is about). and all bridges/devices should ask for same endianness as parent or reverse endianness as parent, but not for big, little, or native endianness. I/O doesn't propagate so there's no way to say something like this. That's the fundamental problem IMHO. There is no such thing as endianness of parent again. This is all wrong. Wrong terminology, wrong concepts. Do not try to use the endian attribute on a bus or bridge, it will only confuse things further. Stick to what is the byte order of your transport (much more precise term, ie. which byte is the lowest address within the host variable that carries the access). Ben.
Re: [Qemu-devel] [Qemu-ppc] [PATCH v3 11/14] ioport: Switch dispatching to memory core layer
On 12 July 2013 23:50, Benjamin Herrenschmidt b...@kernel.crashing.org wrote: On Fri, 2013-07-12 at 19:26 +0100, Peter Maydell wrote: It's not wrong when the hardware actually does a byteswap at some level in the memory hierarchy. You can see this for instance on ARMv7M systems, where byteswapping for bigendian happens at an intermediate level that not all accesses go through: [CPU] [byteswap here] -- [memory and ext. devices] | -- [internal memory mapped devices] so some things see always little endian regardless. Ugh ? That's so completely fucked up, if that's indeed what the HW is doing this is a piece of trash and the designers are in urgent need of being turned into fertilizer. Unless again you are talking about lane swapping which allows to preserve the byte address invariance when the CPU decides to flip its bus around, but I would have thought that modern CPUs do not do that sort of shit anymore. The block marked byteswap here does byte invariant bigendian, so byte accesses are unchanged, 16 bit accesses have the two words of data flipped, and 32 bit accesses have the four bytes flipped; this happens as the data passes through; addresses are unchanged. It only happens if the CPU is configured by the guest to operate in big-endian mode, obviously. (Contrast 'word invariant bigendian', which is what ARM used to do, where the addresses are changed but the data is not. That would be pretty painful to implement in the memory region API though it is of course trivial in hardware since it is just XORing of the low address bits according to the access size...) Again, the only endian attribute that exists are the byte order of the original access (which byte has the lowest address, regardless of significance of those bytes in the target, ie, purely from a qemu standpoint, in the variable that carries the access around inside qemu, which byte has the lowest address) What does this even mean? At the point where a memory access leaves the CPU (emulation or real hardware) it has (a) an address and (b) a width -- a 16 bit access is neither big nor little endian, it's just a request for 16 bits of data (on real hardware it's typically a bus transaction on a bunch of data lines with some control lines indicating transaction width). Now the CPU emulation may internally be intending to put that data into its emulated register one way round or the other, but that's an internal detail of the CPU emulation. (Similarly for stores.) , and the same on the target device (at which point a concept of significance does apply, but it's a guest driver business to get it right, qemu just need to make sure byte 0 goes to byte 0). Similarly, at the target device end there is no concept of a big endian access -- we make a request for 16 bits of data at a particular address (via the MemoryRegion API) and the device returns 16 bits of data. It's entirely possible to design hardware so that byte access to address X, halfword access to address X and word access to address X all return entirely different data (though it would be a bit perverse.) (As an implementation convenience we may choose to provide helper infrastructure so you don't have to actually implement all of byte/halfword/word access by hand.) If a bridge flips things around in a way that breaks the model, That breaks what model? then add some property describing the flipping properties but don't call it big endian or little endian at the bridge level, that has no meaning, confuses things and introduces breakage like we have seen. I'm happy to call the property byteswap, yes, because that's what it does. If you did two of these in a row you'd get a no-op. (Our other serious endianness problem is that we don't really do very well at supporting a TCG CPU arbitrarily flipping endianness -- TARGET_WORDS_BIGENDIAN is a compile time setting and ideally it should not be.) Our experience is that it actually works fine for almost everything except virtio :-) ie mostly TARGET_WORDS_BIGENDIAN is irrelevant (and should be). I agree that TARGET_WORDS_BIGENDIAN *should* go away, but it exists currently. Do you actually implement a CPU which does dynamic endianness flipping? Is it at all efficient in the config which is the opposite of whatever TARGET_WORDS_BIGENDIAN says? thanks -- PMM
Re: [Qemu-devel] [Qemu-ppc] [PATCH v3 11/14] ioport: Switch dispatching to memory core layer
On Sat, 2013-07-13 at 00:10 +0100, Peter Maydell wrote: The block marked byteswap here does byte invariant bigendian, so byte accesses are unchanged, 16 bit accesses have the two words of data flipped, and 32 bit accesses have the four bytes flipped; this happens as the data passes through; addresses are unchanged. It only happens if the CPU is configured by the guest to operate in big-endian mode, obviously. (Contrast 'word invariant bigendian', which is what ARM used to do, where the addresses are changed but the data is not. That would be pretty painful to implement in the memory region API though it is of course trivial in hardware since it is just XORing of the low address bits according to the access size...) Which means that ARM switches the byte order of its bus when switching endian which is very very wrong... oh well. PowerPCs operate in both endians and nowadays do not require any adjustement at the bus level. It's simple, the definition that matter and the only definition that matter for data is which byte is at what address and that shouldn't change. For addresses, they should be in a fixed significance order, not change order based on the endianness of the processor. Or to say things differently, byte order of data should be fixed, and the endianness of the bus (which is purely in that case the byte order of addresses) as well. ARM seem to have chosen to go from fixing the byte order of data changing the bus endianness, to changing the byte order of data to preserve the bus endianness, or something along those lines. Both approaches are WRONG. Anyway, whatever, what is done is done, point is, what you have is a byte lane swapper which is similar to what older ppc did which indeed is needed if your bus flips around. I would still not model that using the term endianness of either the bus or bridge. It's again purely a statement of what byte lane coming out corresponds to what *address*, regardless of byte significance. Again, the only endian attribute that exists are the byte order of the original access (which byte has the lowest address, regardless of significance of those bytes in the target, ie, purely from a qemu standpoint, in the variable that carries the access around inside qemu, which byte has the lowest address) What does this even mean? At the point where a memory access leaves the CPU (emulation or real hardware) it has (a) an address and (b) a width -- a 16 bit access is neither big nor little endian, Not from the point of view of the bus indeed. The value inside might or might not have an endianness but that's purely somebody else business. it's just a request for 16 bits of data (on real hardware it's typically a bus transaction on a bunch of data lines with some control lines indicating transaction width). Now the CPU emulation may internally be intending to put that data into its emulated register one way round or the other, but that's an internal detail of the CPU emulation. (Similarly for stores.) My statement above meant (sorry if it wasn't clear) that what matters is that when qemu carries that request around (thus carries those 16-bits in a u16 variable inside qemu itself, ie, the argument of some load/store callback), the only attribute of interest is which of the bytes in that u16 variable is the first in ascending address order. IE. This is a property of the processor bus, it is *defined* which of those 2 bytes that form that 16 bit wide access is supposed to go at what address as part of the bus definition (though ARM seems to flip it around). Obviously, it should be done according to the host endianness, and thus one would expect that qemu just storing that in memory results in the two bytes being laid out in the right order. My point here is that if any conversion at that level is needed, it's purely somewhere in TCG to ensure that what's in the variable carried out of TCG is represented according to the intended byte order of the original access. That's why the word endianness is so confusing. At this point, if anything, the only endianness that exists is the one of the host CPU :-) Now when we cross your byte-lanes adjusting bridge in qemu, two things can happen. - The bridge is configured properly and it's a nop - The bridge is *not* configured properly, and you basically need to perform a lane swap on anything crossing that bridge. I wouldn't call that endian. I wouldn't model that by saying that some range of addresses is LE or BE or Host Endian or whatever ... The best way to represent that in qemu would be to have some kind of lane swap attribute which is set based on the (mis)match of the CPU and bridge configuration. , and the same on the target device (at which point a concept of significance does apply, but it's a guest driver business to get it right, qemu just need to make sure byte 0 goes to byte 0). Similarly, at the target device end there is no concept of a big endian access -- we
Re: [Qemu-devel] [Qemu-ppc] [PATCH v3 11/14] ioport: Switch dispatching to memory core layer
On Thu, 2013-07-11 at 15:28 +0200, Alexander Graf wrote: So IIUC before cpu_inw and inl were doing portio accesses in host native endianness. Now with this change they do little endian accesses. All sensible callers of cpu_inX assume that data is passed in native endianness though and already do the little endian conversion themselves. Semantically having your PCI host bridge do the endianness conversion is the correct way of handling it, as that's where the conversion happens. If it makes life easier to do it in the isa bridging code, that's fine for me too though. But then we'll have to get rid of all endianness swaps that already happen in PCI bridges. Or stop being utterly insane and remove all that endianness crap in bridges etc... :-) The whole thing is completely ass backward to begin with. Cheers, Ben.
Re: [Qemu-devel] [Qemu-ppc] [PATCH v3 11/14] ioport: Switch dispatching to memory core layer
On Thu, 2013-07-11 at 15:28 +0200, Alexander Graf wrote: Semantically having your PCI host bridge do the endianness conversion is the correct way of handling it, as that's where the conversion happens. If it makes life easier to do it in the isa bridging code, that's fine for me too though. But then we'll have to get rid of all endianness swaps that already happen in PCI bridges. BTW. Why would IOs to a PCI VGA device go through an ISA bridge of any kind ? PCI IO space is PCI IO space... whether there is an ISA bridge or not is a separate thing and PCI VGA cards certainly don't sit behind one. Ben.
Re: [Qemu-devel] [Qemu-ppc] [PATCH v3 11/14] ioport: Switch dispatching to memory core layer
Am 12.07.2013 um 00:32 schrieb Benjamin Herrenschmidt b...@kernel.crashing.org: On Thu, 2013-07-11 at 15:28 +0200, Alexander Graf wrote: Semantically having your PCI host bridge do the endianness conversion is the correct way of handling it, as that's where the conversion happens. If it makes life easier to do it in the isa bridging code, that's fine for me too though. But then we'll have to get rid of all endianness swaps that already happen in PCI bridges. BTW. Why would IOs to a PCI VGA device go through an ISA bridge of any kind ? PCI IO space is PCI IO space... whether there is an ISA bridge or not is a separate thing and PCI VGA cards certainly don't sit behind one. We model a single system wide io space today and access to that one happens through you pci host controller. I just messed up the terminology here. Alex Ben.
