lkml.org 
[lkml]   [2015]   [Jul]   [9]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    SubjectRe: [PATCH] KVM: x86: Add host physical address width capability
    Date
    Paolo Bonzini <pbonzini@redhat.com> 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 <lersek@redhat.com>
    >>>> Signed-off-by: Bandan Das <bsd@redhat.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.)
    >
    > 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


    \
     
     \ /
      Last update: 2015-07-09 21:01    [W:3.751 / U:0.104 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site