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 <lersek@xxxxxxxxxx> >>> Signed-off-by: Bandan Das <bsd@xxxxxxxxxx> >>> --- >>> 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. Paolo -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
