On Thu, Feb 23, 2017 at 12:43:37PM +0100, Paolo Bonzini wrote: > > > On 23/02/2017 12:34, Peter Maydell wrote: > > On 23 February 2017 at 10:33, Paolo Bonzini <pbonz...@redhat.com> wrote: > >> > >> > >> On 23/02/2017 11:23, Peter Maydell wrote: > >>> On 23 February 2017 at 10:10, Paolo Bonzini <pbonz...@redhat.com> wrote: > >>>> On 23/02/2017 11:02, Peter Maydell wrote: > >>>>> I'm really not convinced we need DEVICE_HOST_ENDIAN. RAM > >>>>> areas should be target-endian (you can probably define > >>>>> "target endianness" as "the endianness that RAM areas have".) > >>>> > >>>> This is not RAM. This is MMIO, backed by a MMIO area in the host. > >>> > >>> Hmm, I see...the naming is a bit unfortunate if it's not RAM. > >> > >> Yeah, it's called like that because it is backed by a RAMBlock but it > >> returns false for memory_access_is_direct. > > > > We should probably update the doc comment to note that the > > pointer is to host-endianness memory (and that this is not > > like normal RAM which is target-endian)... > > I wouldn't call it host-endianness memory, and I disagree that normal > RAM is target-endian---in both cases it's just a bunch of bytes.
Right. Really, endianness is not a property of the device - even less
so of RAM. It's a property of an individual multibyte value and how
it is interpreted relative to individual byte addresses.
Really the declarations in the MRs are saying: assuming the guest
(software + hardware) does (big|little|target native) accesses on this
device, do the right swaps so we get host native multi-byte values
which match the original multibyte values the guest had in mind.
What we want for memory (both RAM and VFIO MMIO) is: don't even try to
preserve multi-byte values between host and guest views, just preserve
byte address order. Tastes may vary as to whether you call that "host
endian" or "no endian" or "bag-o'-bytesian" or whatever.
> However, the access done by the MemoryRegionOps callbacks needs to match
> the endianness declared by the MemoryRegionOps themselves.
>
> Paolo
>
> >>>> The
> >>>> MemoryRegionOps read from the MMIO area (so the data has host
> >>>> endianness) and do not do any further swap:
> >>>>
> >>>> data = *(uint16_t *)(mr->ram_block->host + addr);
> >>>>
> >>>> Here, the dereference is basically the same as ldl_he_p.
> >>>>
> >>>> If you wanted to make the MemoryRegion use DEVICE_NATIVE_ENDIAN, you'd
> >>>> need to tswap around the access. Or you can use ldl_le_p and
> >>>> DEVICE_LITTLE_ENDIAN (this is what Yongji's patch open codes), or
> >>>> ldl_be_p and DEVICE_BIG_ENDIAN. They are all the same in the end.
> >>>
> >>> Using stl_p &c in a DEVICE_NATIVE_ENDIAN MR would work too, right?
> >>> (This is how all the NATIVE_ENDIAN MRs in exec.c work.)
> >>
> >> Yes, it should, as long as the memcpy(...) of {ld,st}*_he_p is compiled
> >> to a single access, which should be the case.
> >
> > ...and whichever of these approaches we take, we should have
> > a comment which notes that we are converting from the host
> > endianness memory to the endianness specified by the MemoryRegion
> > endianness attribute.
> >
> > thanks
> > -- PMM
> >
>
--
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
signature.asc
Description: PGP signature
