All of lore.kernel.org
 help / color / mirror / Atom feed
From: Sean Christopherson <sean.j.christopherson@intel.com>
To: Tom Lendacky <thomas.lendacky@amd.com>
Cc: kvm@vger.kernel.org, linux-kernel@vger.kernel.org,
	Paolo Bonzini <pbonzini@redhat.com>,
	Vitaly Kuznetsov <vkuznets@redhat.com>,
	Wanpeng Li <wanpengli@tencent.com>,
	Jim Mattson <jmattson@google.com>, Joerg Roedel <joro@8bytes.org>,
	Brijesh Singh <brijesh.singh@amd.com>
Subject: Re: [PATCH v2] KVM: SVM: Override default MMIO mask if memory encryption is enabled
Date: Mon, 6 Jan 2020 14:49:31 -0800	[thread overview]
Message-ID: <20200106224931.GB12879@linux.intel.com> (raw)
In-Reply-To: <d741b3a58769749b7873fea703c027a68b8e2e3d.1577462279.git.thomas.lendacky@amd.com>

On Fri, Dec 27, 2019 at 09:58:00AM -0600, Tom Lendacky wrote:
> The KVM MMIO support uses bit 51 as the reserved bit to cause nested page
> faults when a guest performs MMIO. The AMD memory encryption support uses
> a CPUID function to define the encryption bit position. Given this, it is
> possible that these bits can conflict.
> 
> Use svm_hardware_setup() to override the MMIO mask if memory encryption
> support is enabled. When memory encryption support is enabled the physical
> address width is reduced and the first bit after the last valid reduced
> physical address bit will always be reserved. Use this bit as the MMIO
> mask.
> 
> Fixes: 28a1f3ac1d0c ("kvm: x86: Set highest physical address bits in non-present/reserved SPTEs")
> Suggested-by: Sean Christopherson <sean.j.christopherson@intel.com>
> Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com>
> ---
>  arch/x86/kvm/svm.c | 26 ++++++++++++++++++++++++++
>  1 file changed, 26 insertions(+)
> 
> diff --git a/arch/x86/kvm/svm.c b/arch/x86/kvm/svm.c
> index 122d4ce3b1ab..2cb834b5982a 100644
> --- a/arch/x86/kvm/svm.c
> +++ b/arch/x86/kvm/svm.c
> @@ -1361,6 +1361,32 @@ static __init int svm_hardware_setup(void)
>  		}
>  	}
>  
> +	/*
> +	 * The default MMIO mask is a single bit (excluding the present bit),
> +	 * which could conflict with the memory encryption bit. Check for
> +	 * memory encryption support and override the default MMIO masks if
> +	 * it is enabled.
> +	 */
> +	if (cpuid_eax(0x80000000) >= 0x8000001f) {
> +		u64 msr, mask;
> +
> +		rdmsrl(MSR_K8_SYSCFG, msr);
> +		if (msr & MSR_K8_SYSCFG_MEM_ENCRYPT)  {
> +			/*
> +			 * The physical addressing width is reduced. The first
> +			 * bit above the new physical addressing limit will
> +			 * always be reserved. Use this bit and the present bit
> +			 * to generate a page fault with PFER.RSV = 1.
> +			 */
> +			mask = BIT_ULL(boot_cpu_data.x86_phys_bits);

This doesn't handle the case where x86_phys_bits _isn't_ reduced by SME/SEV
on a future processor, i.e. x86_phys_bits==52.

After staring at things for a while, I think we can handle this issue with
minimal fuss by special casing MKTME in kvm_set_mmio_spte_mask().  I'll
send a patch, I have a related bug fix for kvm_set_mmio_spte_mask() that
touches the same code.

> +			mask |= BIT_ULL(0);
> +
> +			kvm_mmu_set_mmio_spte_mask(mask, mask,
> +						   PT_WRITABLE_MASK |
> +						   PT_USER_MASK);
> +		}
> +	}
> +
>  	for_each_possible_cpu(cpu) {
>  		r = svm_cpu_init(cpu);
>  		if (r)
> -- 
> 2.17.1
> 

  reply	other threads:[~2020-01-06 22:49 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-12-27 15:58 [PATCH v2] KVM: SVM: Override default MMIO mask if memory encryption is enabled Tom Lendacky
2020-01-06 22:49 ` Sean Christopherson [this message]
2020-01-06 23:14   ` Tom Lendacky
2020-01-06 23:38     ` Sean Christopherson
2020-01-07 20:16       ` Tom Lendacky
2020-01-07 22:28         ` Sean Christopherson
2020-01-07 22:54           ` Tom Lendacky
2020-01-07 23:31             ` Sean Christopherson
2020-01-07 23:51               ` Tom Lendacky
2020-01-08  0:04                 ` Sean Christopherson
2020-01-08 13:57                   ` Tom Lendacky
2020-01-08 18:41                     ` Tom Lendacky

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=20200106224931.GB12879@linux.intel.com \
    --to=sean.j.christopherson@intel.com \
    --cc=brijesh.singh@amd.com \
    --cc=jmattson@google.com \
    --cc=joro@8bytes.org \
    --cc=kvm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=pbonzini@redhat.com \
    --cc=thomas.lendacky@amd.com \
    --cc=vkuznets@redhat.com \
    --cc=wanpengli@tencent.com \
    /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.