From: Sean Christopherson <sean.j.christopherson@intel.com>
To: Paolo Bonzini <pbonzini@redhat.com>
Cc: linux-kernel@vger.kernel.org, kvm@vger.kernel.org,
stable@vger.kernel.org
Subject: Re: [PATCH] KVM: x86: use CPUID to locate host page table reserved bits
Date: Wed, 4 Dec 2019 07:29:42 -0800 [thread overview]
Message-ID: <20191204152942.GB6323@linux.intel.com> (raw)
In-Reply-To: <1575471060-55790-1-git-send-email-pbonzini@redhat.com>
On Wed, Dec 04, 2019 at 03:51:00PM +0100, Paolo Bonzini wrote:
> The comment in kvm_get_shadow_phys_bits refers to MKTME, but the same is actually
> true of SME and SEV. Just use CPUID[0x8000_0008].EAX[7:0] unconditionally, it is
> simplest and works even if memory is not encrypted.
>
> Cc: stable@vger.kernel.org
> Reported-by: Tom Lendacky <thomas.lendacky@amd.com>
> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
> ---
> arch/x86/kvm/mmu/mmu.c | 12 ++++--------
> 1 file changed, 4 insertions(+), 8 deletions(-)
>
> diff --git a/arch/x86/kvm/mmu/mmu.c b/arch/x86/kvm/mmu/mmu.c
> index 6f92b40d798c..8b8edfbdbaef 100644
> --- a/arch/x86/kvm/mmu/mmu.c
> +++ b/arch/x86/kvm/mmu/mmu.c
> @@ -538,15 +538,11 @@ void kvm_mmu_set_mask_ptes(u64 user_mask, u64 accessed_mask,
> static u8 kvm_get_shadow_phys_bits(void)
> {
> /*
> - * boot_cpu_data.x86_phys_bits is reduced when MKTME is detected
> - * in CPU detection code, but MKTME treats those reduced bits as
> - * 'keyID' thus they are not reserved bits. Therefore for MKTME
> - * we should still return physical address bits reported by CPUID.
> + * boot_cpu_data.x86_phys_bits is reduced when MKTME or SME are detected
> + * in CPU detection code, but the processor treats those reduced bits as
> + * 'keyID' thus they are not reserved bits. Therefore KVM needs to look at
> + * the physical address bits reported by CPUID.
> */
> - if (!boot_cpu_has(X86_FEATURE_TME) ||
> - WARN_ON_ONCE(boot_cpu_data.extended_cpuid_level < 0x80000008))
> - return boot_cpu_data.x86_phys_bits;
Removing this entirely will break CPUs that don't support leaf 0x80000008.
From a VMX perspective, I'm pretty sure all Intel hardware that supports
VMX is guaranteed to support 0x80000008, but I've no idea about SVM or any
non-Intel CPU, and not supporting 0x80000008 in a virtual machine is
technically legal/possible. We conditioned doing CPUID on TME because TME
would be reported as supported iff 0x80000008 existed.
The extra bit of paranoia doesn't cost much, so play it safe? E.g.:
if (unlikely(boot_cpu_data.extended_cpuid_level < 0x80000008)) {
WARN_ON_ONCE(boot_cpu_has(X86_FEATURE_TME) || SME?);
return boot_cpu_data.x86_phys_bits;
}
return cpuid_eax(0x80000008) & 0xff;
> -
> return cpuid_eax(0x80000008) & 0xff;
> }
>
> --
> 1.8.3.1
>
next prev parent reply other threads:[~2019-12-04 15:29 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-12-04 14:51 [PATCH] KVM: x86: use CPUID to locate host page table reserved bits Paolo Bonzini
2019-12-04 15:29 ` Sean Christopherson [this message]
2019-12-04 15:36 ` Paolo Bonzini
2019-12-11 16:36 ` Sasha Levin
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20191204152942.GB6323@linux.intel.com \
--to=sean.j.christopherson@intel.com \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=pbonzini@redhat.com \
--cc=stable@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.