linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Tom Lendacky <thomas.lendacky@amd.com>
To: Paolo Bonzini <pbonzini@redhat.com>,
	linux-kernel@vger.kernel.org, kvm@vger.kernel.org
Cc: sean.j.christopherson@intel.com, stable@vger.kernel.org
Subject: Re: [PATCH v2] KVM: x86: use CPUID to locate host page table reserved bits
Date: Wed, 4 Dec 2019 09:57:16 -0600	[thread overview]
Message-ID: <8f7e3e87-15dc-2269-f5ee-c3155f91983c@amd.com> (raw)
In-Reply-To: <1575474037-7903-1-git-send-email-pbonzini@redhat.com>

On 12/4/19 9:40 AM, 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 if
> available, it is simplest and works even if memory is not encrypted.

This isn't correct for AMD. The reduction in physical addressing is
correct. You can't set, e.g. bit 45, in the nested page table, because
that will be considered a reserved bit and generate an NPF. When memory
encryption is enabled today, bit 47 is the encryption indicator bit and
bits 46:43 must be zero or else an NPF is generated. The hardware uses
these bits internally based on the whether running as the hypervisor or
based on the ASID of the guest.

Thanks,
Tom

> 
> 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 | 20 ++++++++++++--------
>  1 file changed, 12 insertions(+), 8 deletions(-)
> 
> diff --git a/arch/x86/kvm/mmu/mmu.c b/arch/x86/kvm/mmu/mmu.c
> index 6f92b40d798c..1e4ee4f8de5f 100644
> --- a/arch/x86/kvm/mmu/mmu.c
> +++ b/arch/x86/kvm/mmu/mmu.c
> @@ -538,16 +538,20 @@ 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;
> +	if (likely(boot_cpu_data.extended_cpuid_level >= 0x80000008))
> +		return cpuid_eax(0x80000008) & 0xff;
>  
> -	return cpuid_eax(0x80000008) & 0xff;
> +	/*
> +	 * Quite weird to have VMX or SVM but not MAXPHYADDR; probably a VM with
> +	 * custom CPUID.  Proceed with whatever the kernel found since these features
> +	 * aren't virtualizable (SME/SEV also require CPUIDs higher than 0x80000008).
> +	 */
> +	return boot_cpu_data.x86_phys_bits;
>  }
>  
>  static void kvm_mmu_reset_all_pte_masks(void)
> 

  parent reply	other threads:[~2019-12-04 15:57 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-12-04 15:40 [PATCH v2] KVM: x86: use CPUID to locate host page table reserved bits Paolo Bonzini
2019-12-04 15:48 ` Sean Christopherson
2019-12-10  9:19   ` Paolo Bonzini
2019-12-10 15:37     ` Sean Christopherson
2019-12-04 15:57 ` Tom Lendacky [this message]
2019-12-10  3:53   ` Huang, Kai
2019-12-10  9:18     ` Paolo Bonzini
2019-12-10  9:17   ` Paolo Bonzini
2019-12-11  0:11     ` Huang, Kai
2019-12-11  9:07       ` Paolo Bonzini
2019-12-11 20:48         ` Tom Lendacky
2019-12-11 23:16           ` Huang, Kai

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=8f7e3e87-15dc-2269-f5ee-c3155f91983c@amd.com \
    --to=thomas.lendacky@amd.com \
    --cc=kvm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=pbonzini@redhat.com \
    --cc=sean.j.christopherson@intel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).