qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH] qtest: add read/write accessors with a specific


From: Peter Maydell
Subject: Re: [Qemu-devel] [PATCH] qtest: add read/write accessors with a specific endianness
Date: Wed, 5 Oct 2016 06:53:42 -0700

On 5 October 2016 at 06:49, Cédric Le Goater <address@hidden> 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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]