On 24 January 2014 05:13, Alexander Graf <agraf@xxxxxxx> wrote: > > On 24.01.2014, at 14:09, Paolo Bonzini <pbonzini@xxxxxxxxxx> wrote: > >> Il 24/01/2014 01:01, Peter Maydell ha scritto: >>>> > >>>> > +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.) >> >> I agree, and also the first line should mention userspace. >> >> In PPC I think it's possible or even common to have BE host kernel and LE host userspace (or perhaps vice versa is the common one). > > It was possible on 32bit, but I'm not sure anyone's actively using it :). The thing that was very common (not so much anymore for enterprise distros) is 32-bit user space with 64-bit kernels. Paolo, Alex, good point about BE kernel / LE user-land mix! How KVM kernel code that deals with KVM_MMIO_EXIT can find out what is user process endianity that handles this KVM_MMIO_EXIT? Do we have kernel function that can tell that. "Hey, what is current user-land task endianity? :)". And reverse case, how user-land code that wants to do KVM_MMIO_EXIT can find out what is endianity of kernel? Do we have such system call? "Hey, kernel tell me your endianity :)". Just a thought: should not we instead of trying to implicitly setup endianity by some other side properties like emulator or kernel endianity, let's just do it explicitly. Adding 'endianness' field into current mmio structure is not an option, but maybe there is outside mechanism like KVM features, special ioctl number, through which one can explicitly either set of learn endianity in mmio.data[] for given KVM session. At least, if we don't want to consider mixed BE/LE kernel/user-land, then document should clarify that BE/LE kernel/user-land mix is not supported and assumption here is that they always coincide. Thanks, Victor > > Alex > > > _______________________________________________ > kvmarm mailing list > kvmarm@xxxxxxxxxxxxxxxxxxxxx > https://lists.cs.columbia.edu/cucslists/listinfo/kvmarm -- 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
