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

[David Gibson <david@gibson.dropbear.id.au>]

[-- Attachment #1: Type: text/plain, Size: 2301 bytes --]

On Thu, Oct 06, 2016 at 11:47:36AM +0100, Peter Maydell wrote:
> On 6 October 2016 at 04:45, David Gibson <david@gibson.dropbear.id.au> 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 <clg@kaod.org> 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".

The CPU with what mode and options?

> There's a reason we've got this far without needing anything
> else, and it's that this is the most straightforward use case.

No, I'm pretty sure we've got this far because most of the tests
haven't yet been enabled for a traditionally BE target.

> > 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.

Uh, that's not the intention.  I have some comments on this elsewhere.

The intended semantics are that we do a single atomic write to an
address, but with a specific endianness.

-- 
David Gibson			| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au	| minimalist, thank you.  NOT _the_ _other_
				| _way_ _around_!
http://www.ozlabs.org/~dgibson

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]