From patchwork Fri Jan 24 23:39:42 2014 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Christoffer Dall X-Patchwork-Id: 314102 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by ozlabs.org (Postfix) with ESMTP id 6EE852C00A1 for ; Sat, 25 Jan 2014 10:39:44 +1100 (EST) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751492AbaAXXjn (ORCPT ); Fri, 24 Jan 2014 18:39:43 -0500 Received: from mail-pd0-f182.google.com ([209.85.192.182]:33826 "EHLO mail-pd0-f182.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750872AbaAXXjm (ORCPT ); Fri, 24 Jan 2014 18:39:42 -0500 Received: by mail-pd0-f182.google.com with SMTP id v10so3674929pde.13 for ; Fri, 24 Jan 2014 15:39:42 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:cc:subject:date:message-id; bh=riXQvsA5MZdi5BZxlyKa1tqZXq28hdG6fKh3kATPWgQ=; b=mYFAj3Y6AoafXGtkL/EGFkckUI3TNUavcIHPc4lx/hd/X3aBPXVDdQo7KXc3PKC2f2 Z3zc/mTlQS4pbdi55ZS4G9KF74bhfUFLvMidezIjvWJ+yRdn8yTeQhZ+OZGr3p9z48kY C8fgTF/ut6NPZg7BJnGmmgOwt70d9OCtI4jk3g9bIPLDlDLRXUN7GpvQEibRWRoXH0cI Dklo+aEoirO7SkoEbSKDFA+GvTN7lio9jjj8Do4ulC3ijv2ocePNZ/P1a0tzvUUsXfFJ nYC1i7gjyhi48ina/MoL04zmmHUY56JG5ajT5+sh9mSJYrfyjNkZC8lyGMOK+9JoeW4W oc2g== X-Gm-Message-State: ALoCoQl92e7V3M/7/Jt42uc46SubzOCiFD9hjb1yFTnv2Q5FNzDo8O8M8h6Xf54Tq5T1sYstIwuT X-Received: by 10.66.119.136 with SMTP id ku8mr16791316pab.121.1390606782306; Fri, 24 Jan 2014 15:39:42 -0800 (PST) Received: from localhost.localdomain (c-67-169-181-221.hsd1.ca.comcast.net. [67.169.181.221]) by mx.google.com with ESMTPSA id id1sm6904963pbc.11.2014.01.24.15.39.40 for (version=TLSv1.1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 24 Jan 2014 15:39:41 -0800 (PST) From: Christoffer Dall To: kvm@vger.kernel.org Cc: kvm-ppc@vger.kernel.org, kvmarm@lists.cs.columbia.edu, patches@linaro.org, Christoffer Dall , Marc Zyngier , Peter Maydell , Alexander Graf Subject: [PATCH v2] KVM: Specify byte order for KVM_EXIT_MMIO Date: Fri, 24 Jan 2014 15:39:42 -0800 Message-Id: <1390606782-14724-1-git-send-email-christoffer.dall@linaro.org> X-Mailer: git-send-email 1.8.5.2 Sender: kvm-ppc-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: kvm-ppc@vger.kernel.org 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 [v1 - v2]: - s/host kernel should/host user space should/ Documentation/virtual/kvm/api.txt | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/Documentation/virtual/kvm/api.txt b/Documentation/virtual/kvm/api.txt index 366bf4b..6dbd68c 100644 --- a/Documentation/virtual/kvm/api.txt +++ b/Documentation/virtual/kvm/api.txt @@ -2565,6 +2565,11 @@ 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 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 user space should always be able to do: + val = *(( *)mmio.data). + 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