[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <559E180E.8080308@redhat.com>
Date: Thu, 09 Jul 2015 08:43:26 +0200
From: Laszlo Ersek <lersek@...hat.com>
To: Paolo Bonzini <pbonzini@...hat.com>, Bandan Das <bsd@...hat.com>,
kvm@...r.kernel.org
CC: linux-kernel@...r.kernel.org, qemu-devel@...gnu.org
Subject: Re: [PATCH] KVM: x86: Add host physical address width capability
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 <lersek@...hat.com>
>> Signed-off-by: Bandan Das <bsd@...hat.com>
>> ---
>> 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
>>
>>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists