On 6 October 2016 at 04:45, David Gibson <da...@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 <c...@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". 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
