From mboxrd@z Thu Jan 1 00:00:00 1970 From: Paolo Bonzini Subject: Re: [RFC PATCH] KVM: Specify byte order for KVM_EXIT_MMIO Date: Fri, 24 Jan 2014 14:09:54 +0100 Message-ID: <52E26622.4070303@redhat.com> References: <1390520766-5275-1-git-send-email-christoffer.dall@linaro.org> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: kvm-devel , "kvmarm@lists.cs.columbia.edu" , kvm-ppc , Marc Zyngier , Alexander Graf To: Peter Maydell , Christoffer Dall Return-path: In-Reply-To: Sender: kvm-ppc-owner@vger.kernel.org List-Id: kvm.vger.kernel.org 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: >> > + val = *(( *)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). Paolo