On 5 October 2016 at 06:49, Cédric Le Goater <c...@kaod.org> wrote: > On 10/05/2016 02:31 PM, Peter Maydell wrote: >> Here I definitely disagree. I think it makes much more sense >> for writes to be "what the guest CPU would write", because that's >> where we're injecting them. If we had a test framework where the >> test was talking directly to the device, then maybe, but we don't. > > This is how it all started with the test I wrote. Quite ignorant > of the middle layers, I used cpu_to_be32() as I would have done > on the guest and then realized that qtest was byte-swapping also > in some cases and so the test failed on a BE host.
At this point we're back to "I'd need to look at the actual test and device code to identify what's going wrong"... >>> Basically, the existing byteswaps, instead of removing the need for >>> them in the testcase code, instead mean that target-conditional >>> byteswaps will be *required* in nearly every testcase. It's a recipe >>> for endianness-unsafe testcases. >> >> I prefer the swaps to be explicit in the test cases. If your >> test case running on the real CPU would have had to do >> "swap to LE and then write this word", so does the test >> case in our test framework. If your test case just does >> "write the word", then so does the test. >> >> Most devices IME do not require byteswaps by guest code, >> and I think these functions are confusing -- if you try >> to use them to write tests for ARM devices, for instance, >> the _le versions of these functions will introduce an >> incorrect byteswap on a BE host, even though ARM CPUs and >> devices are typically all LE. > > hmmm, yes I agree :/ My scenario is for a ARM SoC running LE > on a BE host and accessing a BE device. > > So how do we handle the possible bswap due to the host and > guest endianness being different ? I am confused. Should we > try to remove the tswap from qtest ? Which tswap? Last time I worked through the stack of what happens I thought that we had the right set of swaps in the right places. thanks -- PMM
