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: Tue, 7 Jan 2020 16:04:12 -0800 [thread overview]
Message-ID: <20200108000412.GE16987@linux.intel.com> (raw)
In-Reply-To: <c60d15f2-ca10-678c-30aa-5369cf3864c7@amd.com>
On Tue, Jan 07, 2020 at 05:51:51PM -0600, Tom Lendacky wrote:
> On 1/7/20 5:31 PM, Sean Christopherson wrote:
> > AIUI, using phys_bits=48, then the standard scenario is Cbit=47 and some
> > additional bits 46:M are reserved. Applying that logic to phys_bits=52,
> > then Cbit=51 and bits 50:M are reserved, so there's a collision but it's
>
> There's no requirement that the C-bit correspond to phys_bits. So, for
> example, you can have C-bit=51 and phys_bits=48 and so 47:M are reserved.
But then using blindly using x86_phys_bits would break if the PA bits
aren't reduced, e.g. C-bit=47 and phys_bits=47. AFAICT, there's no
requirement that there be reduced PA bits when there is a C-bit. I'm
guessing there aren't plans to ship such CPUs, but I don't see anything
in the APM to prevent such a scenario.
Maybe the least painful approach would be to go with a version of this
patch and add a check that there are indeeded reserved/reduced bits?
Probably with a WARN_ON_ONCE if the check fails.
next prev parent reply other threads:[~2020-01-08 0:04 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
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 [this message]
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=20200108000412.GE16987@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.