Re: [RFC PATCH] KVM: Specify byte order for KVM_EXIT_MMIO

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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.


Alex

--
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




[Index of Archives]     [KVM ARM]     [KVM ia64]     [KVM ppc]     [Virtualization Tools]     [Spice Development]     [Libvirt]     [Libvirt Users]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite Questions]     [Linux Kernel]     [Linux SCSI]     [XFree86]
  Powered by Linux