From: Zhi Wang <zhi.wang.linux@gmail.com>
To: "Nikunj A. Dadhania" <nikunj@amd.com>
Cc: linux-kernel@vger.kernel.org, x86@kernel.org,
kvm@vger.kernel.org, bp@alien8.de, mingo@redhat.com,
tglx@linutronix.de, dave.hansen@linux.intel.com,
seanjc@google.com, pbonzini@redhat.com, thomas.lendacky@amd.com,
michael.roth@amd.com, David Rientjes <rientjes@google.com>,
stable@kernel.org
Subject: Re: [PATCH v5] x86/sev: Add SEV-SNP guest feature negotiation support
Date: Mon, 16 Jan 2023 13:39:48 +0200 [thread overview]
Message-ID: <20230116133948.0000474b@gmail.com> (raw)
In-Reply-To: <4bca96ee-3665-5503-bb88-baae98e700e2@amd.com>
On Mon, 16 Jan 2023 13:53:56 +0530
"Nikunj A. Dadhania" <nikunj@amd.com> wrote:
> On 13/01/23 17:23, Zhi Wang wrote:
> > On Thu, 12 Jan 2023 14:11:39 +0530
> > Nikunj A Dadhania <nikunj@amd.com> wrote:
> >
>
> >> diff --git a/Documentation/x86/amd-memory-encryption.rst
> >> b/Documentation/x86/amd-memory-encryption.rst index
> >> a1940ebe7be5..b3adc39d7735 100644 ---
> >> a/Documentation/x86/amd-memory-encryption.rst +++
> >> b/Documentation/x86/amd-memory-encryption.rst @@ -95,3 +95,39 @@ by
> >> supplying mem_encrypt=on on the kernel command line. However, if BIOS
> >> does not enable SME, then Linux will not be able to activate memory
> >> encryption, even if configured to do so by default or the mem_encrypt=on
> >> command line parameter is specified. +
> >> +Secure Nested Paging (SNP)
> >> +==========================
> >> +
> >> +SEV-SNP introduces new features (SEV_FEATURES[1:63]) which can be
> >> enabled +by the hypervisor for security enhancements. Some of these
> >> features need +guest side implementation to function correctly. The
> >> below table lists the +expected guest behavior with various possible
> >> scenarios of guest/hypervisor +SNP feature support.
> >> +
>
> > "guest needs implementation" seems a little bit confusing. I suppose it
> > means the feature is mandatory for the guest.
>
> That is not correct. None of these features are mandatory for the guest.
> The hypervisor can enable this feature without the knowledge of guest
> kernel support. So there should be a mechanism in the guest to detect this
> and fail the boot if needed.
>
> > If so, on the second row
> > guest can boot without it. Some explanation?
>
> In the first and second row, HV has not enabled the feature, so the
> guest should boot fine irrespective of "Guest needs implementation".
>
Feel free to educate me if I understand correctly or not:
There are two kinds of features in SEV_FEATURES:
1. Features that HV can freely enable/disable and they won't distrub the guest.
HV | Guest needs impl | Guest has impl | Result
Y/N N X (not necessary) Boot
2. Features that a guest has to be aware of and handle when HV enables them.
HV | Guest needs impl | Guest has impl | Result
N Y X (Dont care) Boot
Y Y N Fail
Y Y Y Boot
> >> +| No | No | No | Boot |
>
> >> +| No | Yes | No | Boot |
>
>
> >> ++-----------------+---------------+---------------+------------------+
> >> +| Feature Enabled | Guest needs | Guest has | Guest boot |
> >> +| by the HV | implementation| implementation| behaviour |
> >> ++=================+===============+===============+==================+>> +| No | No | No | Boot |
> >> +| | | | |
> >> ++-----------------+---------------+---------------+------------------+
> >> +| No | Yes | No | Boot |
> >> +| | | | |
> >> ++-----------------+---------------+---------------+------------------+
> >> +| No | Yes | Yes | Boot |
> >> +| | | | |
> >> ++-----------------+---------------+---------------+------------------+
> >> +| Yes | No | No | Boot with |
> >> +| | | | feature enabled |
> >> ++-----------------+---------------+---------------+------------------+
> >> +| Yes | Yes | No | Graceful boot |
> >> +| | | | failure |
> >> ++-----------------+---------------+---------------+------------------+
> >> +| Yes | Yes | Yes | Boot with |
> >> +| | | | feature enabled |
> >> ++-----------------+---------------+---------------+------------------+
> >> +
> >> +More details in AMD64 APM[1] Vol 2: 15.34.10 SEV_STATUS MSR
> >> +
> >> +[1] https://www.amd.com/system/files/TechDocs/40332_4.05.pdf
> >
> > Probably update the link here as well.
>
> Sure.
>
> >> diff --git a/arch/x86/include/uapi/asm/svm.h
> >> b/arch/x86/include/uapi/asm/svm.h index f69c168391aa..a04fe07eb9a8 100644
> >> --- a/arch/x86/include/uapi/asm/svm.h
> >> +++ b/arch/x86/include/uapi/asm/svm.h
> >> @@ -116,6 +116,12 @@
> >> #define SVM_VMGEXIT_AP_CREATE 1
> >> #define SVM_VMGEXIT_AP_DESTROY 2
> >> #define SVM_VMGEXIT_HV_FEATURES 0x8000fffd
> >> +#define SVM_VMGEXIT_TERM_REQUEST 0x8000fffe
> >> +#define SVM_VMGEXIT_TERM_REASON(reason_set, reason_code) \
> >> + /* SW_EXITINFO1[3:0] */ \
> >> + (((((u64)reason_set) & 0xf)) | \
> > ^
> > One extra space before 0xf should be removed.
>
> Sure.
>
> Thanks for the review.
>
> Nikunj
>
next prev parent reply other threads:[~2023-01-16 11:40 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-01-12 8:41 [PATCH v5] x86/sev: Add SEV-SNP guest feature negotiation support Nikunj A Dadhania
2023-01-12 14:42 ` Tom Lendacky
2023-01-13 5:29 ` Nikunj A. Dadhania
2023-01-13 11:53 ` Zhi Wang
2023-01-16 5:38 ` Nikunj A. Dadhania
2023-01-16 8:23 ` Nikunj A. Dadhania
2023-01-16 11:39 ` Zhi Wang [this message]
2023-01-16 11:43 ` Nikunj A. Dadhania
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=20230116133948.0000474b@gmail.com \
--to=zhi.wang.linux@gmail.com \
--cc=bp@alien8.de \
--cc=dave.hansen@linux.intel.com \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=michael.roth@amd.com \
--cc=mingo@redhat.com \
--cc=nikunj@amd.com \
--cc=pbonzini@redhat.com \
--cc=rientjes@google.com \
--cc=seanjc@google.com \
--cc=stable@kernel.org \
--cc=tglx@linutronix.de \
--cc=thomas.lendacky@amd.com \
--cc=x86@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.