KVM: x86: Add a capability for GUEST_MAXPHYADDR < HOST_MAXPHYADDR support
authorMohammed Gamal <mgamal@redhat.com>
Fri, 10 Jul 2020 15:48:11 +0000 (17:48 +0200)
committerPaolo Bonzini <pbonzini@redhat.com>
Fri, 10 Jul 2020 21:01:53 +0000 (17:01 -0400)
commit3edd68399dc155b80335244c8c2673eaa652931a
treec9416694c43d066b4fa198d8c42e5ec3e729a04c
parent8c4182bd27cafc2b0f94564485c89ed366c1572c
KVM: x86: Add a capability for GUEST_MAXPHYADDR < HOST_MAXPHYADDR support

This patch adds a new capability KVM_CAP_SMALLER_MAXPHYADDR which
allows userspace to query if the underlying architecture would
support GUEST_MAXPHYADDR < HOST_MAXPHYADDR and hence act accordingly
(e.g. qemu can decide if it should warn for -cpu ..,phys-bits=X)

The complications in this patch are due to unexpected (but documented)
behaviour we see with NPF vmexit handling in AMD processor.  If
SVM is modified to add guest physical address checks in the NPF
and guest #PF paths, we see the followning error multiple times in
the 'access' test in kvm-unit-tests:

            test pte.p pte.36 pde.p: FAIL: pte 2000021 expected 2000001
            Dump mapping: address: 0x123400000000
            ------L4: 24c3027
            ------L3: 24c4027
            ------L2: 24c5021
            ------L1: 1002000021

This is because the PTE's accessed bit is set by the CPU hardware before
the NPF vmexit. This is handled completely by hardware and cannot be fixed
in software.

Therefore, availability of the new capability depends on a boolean variable
allow_smaller_maxphyaddr which is set individually by VMX and SVM init
routines. On VMX it's always set to true, on SVM it's only set to true
when NPT is not enabled.

CC: Tom Lendacky <thomas.lendacky@amd.com>
CC: Babu Moger <babu.moger@amd.com>
Signed-off-by: Mohammed Gamal <mgamal@redhat.com>
Message-Id: <20200710154811.418214-10-mgamal@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
arch/x86/include/asm/kvm_host.h
arch/x86/kvm/svm/svm.c
arch/x86/kvm/vmx/vmx.c
arch/x86/kvm/x86.c
include/uapi/linux/kvm.h