From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:60834) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZD5YV-0008DG-9a for qemu-devel@nongnu.org; Thu, 09 Jul 2015 02:43:36 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZD5YQ-0005cE-9p for qemu-devel@nongnu.org; Thu, 09 Jul 2015 02:43:35 -0400 Received: from mx1.redhat.com ([209.132.183.28]:41729) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZD5YQ-0005c2-4w for qemu-devel@nongnu.org; Thu, 09 Jul 2015 02:43:30 -0400 Message-ID: <559E180E.8080308@redhat.com> Date: Thu, 09 Jul 2015 08:43:26 +0200 From: Laszlo Ersek MIME-Version: 1.0 References: <559E101A.7080601@redhat.com> In-Reply-To: <559E101A.7080601@redhat.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH] KVM: x86: Add host physical address width capability List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Paolo Bonzini , Bandan Das , kvm@vger.kernel.org Cc: linux-kernel@vger.kernel.org, qemu-devel@nongnu.org On 07/09/15 08:09, Paolo Bonzini wrote: > > > On 09/07/2015 00:36, Bandan Das wrote: >> Let userspace inquire the maximum physical address width >> of the host processors; this can be used to identify maximum >> memory that can be assigned to the guest. >> >> Reported-by: Laszlo Ersek >> Signed-off-by: Bandan Das >> --- >> arch/x86/kvm/x86.c | 3 +++ >> include/uapi/linux/kvm.h | 1 + >> 2 files changed, 4 insertions(+) >> >> diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c >> index bbaf44e..97d6746 100644 >> --- a/arch/x86/kvm/x86.c >> +++ b/arch/x86/kvm/x86.c >> @@ -2683,6 +2683,9 @@ int kvm_vm_ioctl_check_extension(struct kvm *kvm, long ext) >> case KVM_CAP_NR_MEMSLOTS: >> r = KVM_USER_MEM_SLOTS; >> break; >> + case KVM_CAP_PHY_ADDR_WIDTH: >> + r = boot_cpu_data.x86_phys_bits; >> + break; > > Userspace can just use CPUID, can't it? I believe KVM's cooperation is necessary, for the following reason: The truncation only occurs when the guest-phys <-> host-phys translation is done in hardware, *and* the phys bits of the host processor are insufficient to represent the highest guest-phys address that the guest will ever face. The first condition (of course) means that the truncation depends on EPT being enabled. (I didn't test on AMD so I don't know if RVI has the same issue.) If EPT is disabled, either because the host processor lacks it, or because the respective kvm_intel module parameter is set so, then the issue cannot be experienced. Therefore I believe a KVM patch is necessary. However, this specific patch doesn't seem sufficient; it should also consider whether EPT is enabled. (And the ioctl should be perhaps renamed to reflect that -- what QEMU needs to know is not the raw physical address width of the host processor, but whether that width will cause EPT to silently truncate high guest-phys addresses.) Thanks Laszlo > > Paolo > >> case KVM_CAP_PV_MMU: /* obsolete */ >> r = 0; >> break; >> diff --git a/include/uapi/linux/kvm.h b/include/uapi/linux/kvm.h >> index 716ad4a..e7949a1 100644 >> --- a/include/uapi/linux/kvm.h >> +++ b/include/uapi/linux/kvm.h >> @@ -817,6 +817,7 @@ struct kvm_ppc_smmu_info { >> #define KVM_CAP_DISABLE_QUIRKS 116 >> #define KVM_CAP_X86_SMM 117 >> #define KVM_CAP_MULTI_ADDRESS_SPACE 118 >> +#define KVM_CAP_PHY_ADDR_WIDTH 119 >> >> #ifdef KVM_CAP_IRQ_ROUTING >> >>