On 23 January 2014 23:46, Christoffer Dall <christoffer.dall@xxxxxxxxxx> 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> > --- > 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..fb7c7e4 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 kernel should always be able to do: > +<type> val = *((<type> *)mmio.data). I think this would be better phrased as "The host userspace should always", since this documentation is supposed to be telling userspace what the kernel's contract with it is, not the kernel keeping notes for itself on its own implementation. (It also clarifies what the intention is for the obscure and maybe-we'll-never-implement-this case of an LE host kernel using a compatibility interface to run the host userspace (QEMU) as a BE process which sees the same ABI a BE kernel provides, without actually dragging that red herring explicitly into the documentation.) On the general semantics I am entirely in agreement with the clarification. thanks -- PMM -- 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
