public inbox for kvm@vger.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 15:38:46 -0800	[thread overview]
Message-ID: <20200106233846.GC12879@linux.intel.com> (raw)
In-Reply-To: <f5c2e60c-536f-e0cd-98b9-86e6da82e48f@amd.com>

On Mon, Jan 06, 2020 at 05:14:04PM -0600, Tom Lendacky wrote:
> On 1/6/20 4:49 PM, Sean Christopherson wrote:
> > 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.
> 
> Not sure I follow. If MSR_K8_SYSCFG_MEM_ENCRYPT is set then there will
> always be a reduction in physical addressing (so I'm told).

Hmm, I'm going off APM Vol 2, which states, or at least strongly implies,
that reducing the PA space is optional.  Section 7.10.2 is especially
clear on this:

  In implementations where the physical address size of the processor is
  reduced when memory encryption features are enabled, software must
  ensure it is executing from addresses where these upper physical address
  bits are 0 prior to setting SYSCFG[MemEncryptionModEn].

But, hopefully the other approach I have in mind actually works, as it's
significantly less special-case code and would naturally handle either
case, i.e. make this a moot point.


Entry on SYSCFG:

  3.2.1 System Configuration Register (SYSCFG)

  ...

  MemEncryptionMode. Bit 23.  Setting this bit to 1 enables the SME and
  SEV memory encryption features.

The SME entry the above links to says:

  7.10.1 Determining Support for Secure Memory Encryption

  ...

  Additionally, in some implementations, the physical address size of the
  processor may be reduced when memory encryption features are enabled, for
  example from 48 to 43 bits. In this case the upper physical address bits are
  treated as reserved when the feature is enabled except where otherwise
  indicated. When memory encryption is supported in an implementation, CPUID
  Fn8000_001F[EBX] reports any physical address size reduction present. Bits
  reserved in this mode are treated the same as other page table reserved bits,
  and will generate a page fault if found to be non-zero when used for address
  translation.

  ...

  7.10.2 Enabling Memory Encryption Extensions

  Prior to using SME, memory encryption features must be enabled by setting
  SYSCFG MSR bit 23 (MemEncryptionModEn) to 1. In implementations where the
  physical address size of the processor is reduced when memory encryption
  features are enabled, software must ensure it is executing from addresses where
  these upper physical address bits are 0 prior to setting
  SYSCFG[MemEncryptionModEn]. Memory encryption is then further controlled via
  the page tables.

  reply	other threads:[~2020-01-06 23:38 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
2020-01-06 23:14   ` Tom Lendacky
2020-01-06 23:38     ` Sean Christopherson [this message]
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=20200106233846.GC12879@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox