Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753958AbbGIScx (ORCPT ); Thu, 9 Jul 2015 14:32:53 -0400 Received: from mx1.redhat.com ([209.132.183.28]:42979 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752639AbbGIScn (ORCPT ); Thu, 9 Jul 2015 14:32:43 -0400 From: Bandan Das To: Paolo Bonzini Cc: Laszlo Ersek , kvm@vger.kernel.org, linux-kernel@vger.kernel.org, qemu-devel@nongnu.org Subject: Re: [PATCH] KVM: x86: Add host physical address width capability References: <559E101A.7080601@redhat.com> <559E180E.8080308@redhat.com> <559E6BE5.4030000@redhat.com> Date: Thu, 09 Jul 2015 14:32:41 -0400 In-Reply-To: <559E6BE5.4030000@redhat.com> (Paolo Bonzini's message of "Thu, 9 Jul 2015 14:41:09 +0200") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2931 Lines: 69 Paolo Bonzini writes: > On 09/07/2015 08:43, Laszlo Ersek wrote: >> 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.) > > Right; if you want to consider whether EPT is enabled (which is the > right thing to do, albeit it makes for a much bigger patch) a KVM patch > is necessary. In that case you also need to patch the API documentation. Note that this patch really doesn't do anything except for printing a message that something might potentially go wrong. Without EPT, you don't hit the processor limitation with your setup, but the user should nevertheless still be notified. In fact, I think shadow paging code should also emulate this behavior if the gpa is out of range. > Paolo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/