On 24 January 2014 07:23, Victor Kamensky <victor.kamensky@xxxxxxxxxx> wrote: > 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. Other thing with mmio.len need clarification: please specify what mmio.len values are allowed. It seems that it was implied that len could be only power of 2 in range between 1 and 8. I would rather see that it is spelled out. I think code on all sides of KVM_EXIT_MMIO already make such assumption. Now when you talk about integers values on "bus in real hardware" power of 2 sizes implied Also note for memory pieces with sizes other than 2, 4, 8 endianness is not defined. > > Also if you use ints on real bus as description, you may want to clarify > restrictions on mmio.len. Basically on 32 bit platform (i.e like V7 > ARM) one cannot have mmio.len=8, because one cannot have 64bit > value on 32bit data bus. Without such clarification introduction of > text like "the value as it would go on the bus in real hardware" is > confusing for len=8 for emulated CPUs where real busses are > 32bit. > > If ldrd/strd would be emulated on ARMV7 one would need to use > mmio twice to pass required data in either direction using len=4 .. > > Thanks, > Victor > >> The host kernel should always be able to do: >>>>> > +<type> val = *((<type> *)mmio.data). would it be prudent to say that it is just integer <type> here. Thanks, Victor >>>> 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. >> >> >> Alex >> >> >> _______________________________________________ >> 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
