From patchwork Tue Jan 28 16:28: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: 314751 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 4A3A12C00A7 for ; Wed, 29 Jan 2014 03:28:52 +1100 (EST) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754866AbaA1Q2q (ORCPT ); Tue, 28 Jan 2014 11:28:46 -0500 Received: from mail-pd0-f181.google.com ([209.85.192.181]:43327 "EHLO mail-pd0-f181.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754321AbaA1Q2q (ORCPT ); Tue, 28 Jan 2014 11:28:46 -0500 Received: by mail-pd0-f181.google.com with SMTP id y10so531346pdj.26 for ; Tue, 28 Jan 2014 08:28:45 -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=HvJ0fJTzjOs95KTh73BY/HrZCxXPzsiqVkRLy30q5DA=; b=Xgyi+1rHmP3etStrMVPdEHO9wVXN1FY7F6E5mCtaqd65FfRLaqAKn27KQ3F7dKiAxO auB8z7XQ7JQi9CtbDeGdOTs9LooiHYm0cH36t05VaKd+QNeTRTZWr2wlnazTlRHqZvib HNJct/8VdFsODiDMt+IZFhOMLsCELMdMb0gzM+YjUJytalCEEXxPEmxLpYsILrQT+3oR cKOZ2UarEDlAnX5HvfmNOpX41Z0/IDi30iSqV9f51LUG5BzBR/vHgU9Ud9bjKxBxUg76 ttFSEs6Zo8sfkIVn8BgR7NoyXpXFCwqp+hsc4pzq9g/urCHmxfLoVtAWRjX9ZkaEkHUj GbOw== X-Gm-Message-State: ALoCoQna5OQYzO3UI9kswB+CCRE+YxQ45mWB6konJ9GmxzCIPMr8++EYpseZM/F4BzAItPv/Rf0U X-Received: by 10.68.198.68 with SMTP id ja4mr2553040pbc.24.1390926525497; Tue, 28 Jan 2014 08:28:45 -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 zc5sm43967656pbc.41.2014.01.28.08.28.43 for (version=TLSv1.1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 28 Jan 2014 08:28:44 -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 v3] KVM: Specify byte order for KVM_EXIT_MMIO Date: Tue, 28 Jan 2014 08:28:42 -0800 Message-Id: <1390926522-18267-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 Acked-by: Alexander Graf Acked-by: Marc Zyngier --- 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