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: Thu, 6 Oct 2016 11:47:36 +0100

On 6 October 2016 at 04:45, David Gibson <address@hidden> wrote:
> On Wed, Oct 05, 2016 at 07:20:52AM -0700, Peter Maydell wrote:
>> On 5 October 2016 at 07:00, Cédric Le Goater <address@hidden> wrote:
>> > On 10/05/2016 03:53 PM, Peter Maydell wrote:
>> >> 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.
>> >
>> > The one I am talking about are under qtest_process_command(),
>> > see below.
>>
>> Those are correct and required, and they do not change
>> the overall behaviour of the system depending on the host
>> endianness. (They convert 32-bit values to "bag of
>> bytes in guest order" which is what the cpu_physical_memory_*
>> functions want.)
>
> These functions are correct for the defined semantics of the
> readw/readl operations, but those semantics are not useful.

?? They're the most obvious and required semantics: "act
like the CPU just did a word/halfword/byte read/write".
There's a reason we've got this far without needing anything
else, and it's that this is the most straightforward use case.

> This proposal is introducing alternate functions with the more useful
> semantics which are "convert a 32-bit value to a bag of bytes in LE
> order" or "convert a 32-bit value to a bag of bytes in BE order"
> depending on which variant you choose.

It's adding functions whose semantics are "act like the
CPU wrote this value to some RAM and then memcpy()ed it to
the device". I think devices whose usage model is "memcpy bytes
to me" are rare to nonexistent.

thanks
-- PMM



reply via email to

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