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 -- To unsubscribe from this list: send the line "unsubscribe kvm-ppc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
