On 24 January 2014 15:51, Scott Wood <scottwood@xxxxxxxxxxxxx> wrote: > On Fri, 2014-01-24 at 15:39 -0800, Christoffer Dall wrote: >> The KVM API documentation is not clear about the semantics of the data >> field on the mmio struct on the kvm_run struct. >> >> This has become problematic when supporting ARM guests on big-endian >> host systems with guests of both endianness types, because it is unclear >> how the data should be exported to user space. >> >> This should not break with existing implementations as all supported >> existing implementations of known user space applications (QEMU and >> kvmtools for virtio) only support default endianness of the >> architectures on the host side. >> >> Cc: Marc Zyngier <marc.zyngier@xxxxxxx> >> Cc: Peter Maydell <peter.maydell@xxxxxxxxxx> >> Cc: Alexander Graf <agraf@xxxxxxx> >> Signed-off-by: Christoffer Dall <christoffer.dall@xxxxxxxxxx> >> --- >> Changes [v1 - v2]: >> - s/host kernel should/host user space should/ >> >> Documentation/virtual/kvm/api.txt | 5 +++++ >> 1 file changed, 5 insertions(+) >> >> diff --git a/Documentation/virtual/kvm/api.txt b/Documentation/virtual/kvm/api.txt >> index 366bf4b..6dbd68c 100644 >> --- a/Documentation/virtual/kvm/api.txt >> +++ b/Documentation/virtual/kvm/api.txt >> @@ -2565,6 +2565,11 @@ executed a memory-mapped I/O instruction which could not be satisfied >> by kvm. The 'data' member contains the written data if 'is_write' is >> true, and should be filled by application code otherwise. >> >> +The 'data' member byte order is host kernel native endianness, regardless of >> +the endianness of the guest, and represents the the value as it would go on the >> +bus in real hardware. The host user space should always be able to do: >> +<type> val = *((<type> *)mmio.data). > > Host userspace should be able to do that with what results? It would > only produce a directly usable value if host endianness is the same as > the emulated device's endianness. > > I'm not sure that "host kernel native endianness" is an accurate way of > describing what currently happens. Regardless of host or guest > endianness, the guest should be swapping the value as necessary to > ensure that the value that goes on the (real or emulated) bus is the > same. > > Plus, if it were really "as it would go on the bus" the value wouldn't > necessarily be left justified within data[], depending on how the bus > works. > > How about a wording like this: > > The 'data' member contains, in its first 'len' bytes, the value as it > would appear if the guest had accessed memory rather than I/O. Scott, Yes! Thank you so much! Completely agree. You managed elegantly to express in two lines, what I failed to communicate with hundreds lines of my emails in last few days on this and other email thread. - Victor > -Scott > > > _______________________________________________ > kvmarm mailing list > kvmarm@xxxxxxxxxxxxxxxxxxxxx > https://lists.cs.columbia.edu/cucslists/listinfo/kvmarm -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
