From mboxrd@z Thu Jan 1 00:00:00 1970 From: Marc Zyngier Subject: Re: [PATCH v3] KVM: Specify byte order for KVM_EXIT_MMIO Date: Mon, 17 Mar 2014 19:00:20 +0000 Message-ID: <878us87irf.fsf@approximate.cambridge.arm.com> References: <1390926522-18267-1-git-send-email-christoffer.dall@linaro.org> <20140314042756.GA25405@cbox> Mime-Version: 1.0 Content-Type: text/plain Cc: "kvm\@vger.kernel.org" , "kvm-ppc\@vger.kernel.org" , "kvmarm\@lists.cs.columbia.edu" , "patches\@linaro.org" , Peter Maydell , "agraf\@suse.de" To: Christoffer Dall Return-path: Received: from fw-tnat.austin.arm.com ([217.140.110.23]:34512 "EHLO collaborate-mta1.arm.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1751038AbaCQTAe (ORCPT ); Mon, 17 Mar 2014 15:00:34 -0400 In-Reply-To: <20140314042756.GA25405@cbox> (Christoffer Dall's message of "Fri, 14 Mar 2014 04:27:56 +0000") Sender: kvm-owner@vger.kernel.org List-ID: On Fri, Mar 14 2014 at 4:27:56 am GMT, Christoffer Dall wrote: > On Tue, Jan 28, 2014 at 08:28:42AM -0800, Christoffer Dall 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 >> Cc: Peter Maydell >> Cc: Alexander Graf >> Signed-off-by: Christoffer Dall >> --- >> Changes [v2 - v3]: >> - Change the semantics and wordings as per Scott's, Avi's, and Ben's >> suggestions. >> >> Changes [v1 - v2]: >> - s/host kernel should/host user space should/ >> >> Documentation/virtual/kvm/api.txt | 4 ++++ >> 1 file changed, 4 insertions(+) >> >> diff --git a/Documentation/virtual/kvm/api.txt b/Documentation/virtual/kvm/api.txt >> index 366bf4b..e11f09d 100644 >> --- a/Documentation/virtual/kvm/api.txt >> +++ b/Documentation/virtual/kvm/api.txt >> @@ -2565,6 +2565,10 @@ 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 contains, in its first 'len' bytes, the value as it would >> +appear if the VCPU performed a load or store of the appropriate width directly >> +to the byte array. >> + >> NOTE: For KVM_EXIT_IO, KVM_EXIT_MMIO, KVM_EXIT_OSI, KVM_EXIT_DCR, >> KVM_EXIT_PAPR and KVM_EXIT_EPR the corresponding >> operations are complete (and guest state is consistent) only after userspace >> -- >> 1.8.5.2 >> > > Any more comments on this one, or can it be applied? I think we should go ahead and apply this. Having dark corners in the ABI is not a very good thing, and bi-endianness seems to be quite fashionnable these days... ;-) Acked-by: Marc Zyngier M. -- Jazz is not dead. It just smells funny.