From: Sean Christopherson <seanjc@google.com>
To: "Pratik R. Sampat" <pratikrajesh.sampat@amd.com>
Cc: kvm@vger.kernel.org, pbonzini@redhat.com, pgonda@google.com,
thomas.lendacky@amd.com, michael.roth@amd.com, shuah@kernel.org,
linux-kselftest@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v3 2/9] KVM: selftests: Add a basic SNP smoke test
Date: Wed, 30 Oct 2024 06:46:24 -0700 [thread overview]
Message-ID: <ZyI4cRLsaTQ3FMk7@google.com> (raw)
In-Reply-To: <71f0fb41-d5a7-450b-ba47-ad6c39dce586@amd.com>
On Mon, Oct 28, 2024, Pratik R. Sampat wro4te:
> On 10/28/2024 12:55 PM, Sean Christopherson wrote:
> > On Mon, Oct 21, 2024, Pratik R. Sampat wrote:
> >>>> + if (unlikely(!is_smt_active()))
> >>>> + snp_policy &= ~SNP_POLICY_SMT;
> >>>
> >>> Why does SNP_POLICY assume SMT? And what is RSVD_MBO? E.g. why not this?
> >>>
> >>> u64 policy = is_smt_active() ? SNP_POLICY_SMT : SNP_POLICY;
> >>>
> >>
> >> I think most systems support SMT so I enabled the bit in by default and
> >> only unset it when there isn't any support.
> >
> > That's confusing though, because you're mixing architectural defines with semi-
> > arbitrary selftests behavior. RSVD_MBO on the other is apparently tightly coupled
> > with SNP, i.e. SNP can't exist without that bit, so it makes sense that RSVD_MBO
> > needs to be part of SNP_POLICY
> >
> > If you want to have a *software*-defined default policy, then make it obvious that
> > it's software defined. E.g. name the #define SNP_DEFAULT_POLICY, not simply
> > SNP_POLICY, because the latter is too easily misconstrued as the base SNP policy,
> > which it is not. That said, IIUC, SMT *must* match the host configuration, i.e.
> > whether or not SMT is set is non-negotiable. In that case, there's zero value in
> > defining SNP_DEFAULT_POLICY, because it can't be a sane default for all systems.
> >
>
> Right, SMT should match the host configuration. Would a
> SNP_DEFAULT_POLICY work if we made it check for SMT too in the macro?
>
> Instead of,
> #define SNP_POLICY (SNP_POLICY_SMT | SNP_POLICY_RSVD_MBO)
>
> Have something like this instead to make it generic and less ambiguous?
> #define SNP_DEFAULT_POLICY() \
> ({ \
> SNP_POLICY_RSVD_MBO | (is_smt_active() ? SNP_POLICY_SMT : 0); \
> })
No, unless it's the least awful option, don't hide dynamic functionality in a macro
that looks like it holds static data. The idea is totally fine, but put it in an
actual helper, not a macro, _if_ there's actually a need for a default policy.
If there's only ever one main path that creates SNP VMs, then I don't see the point
in specifying a default policy.
> > Side topic, I assume one of SEV_POLICY_NO_DBG or SNP_POLICY_DBG *must* be specified,
> > and that they are mutualy exclusive? E.g. what happens if the full policy is simply
> > SNP_POLICY_RSVD_MBO?
>
> SEV_POLICY_NO_DBG is mainly for the guest policy structure of SEV and
> SEV-ES - pg 31, Table 2
> https://www.amd.com/content/dam/amd/en/documents/epyc-technical-docs/programmer-references/55766_SEV-KM_API_Specification.pdf
>
> and, SNP_POLICY_DBG is a bit in the guest policy structure of SNP - pg
> 27, Table 9
> https://www.amd.com/content/dam/amd/en/documents/epyc-technical-docs/specifications/56860.pdf
>
> In the former, a SEV guest disables debugging if SEV_POLICY_NO_DBG is
> set. Similarly, a SNP guest enables debugging if SNP_POLICY_DBG is set.
Ugh, one is SEV_xxx, the other is SNP_xxx. Argh! And IIUC, they are mutually
exclusive (totally separate thigns?), because SNP guests use an 8-byte structure,
whereas SEV/SEV-ES use a 4-byte structure, and with different layouts.
That means this is _extremely_ confusing. Separate the SEV_xxx defines from the
SNP_xxx defines, because other than a name, they have nothing in common.
+/* Minimum firmware version required for the SEV-SNP support */
+#define SNP_FW_REQ_VER_MAJOR 1
+#define SNP_FW_REQ_VER_MINOR 51
Side topic, why are these hardcoded? And where did they come from? If they're
arbitrary KVM selftests values, make that super duper clear.
+#define SNP_POLICY_MINOR_BIT 0
+#define SNP_POLICY_MAJOR_BIT 8
s/BIT/SHIFT. "BIT" implies they are a single bit, which is obviously not the
case. But I vote to omit the extra #define entirely and just open code the shift
in the SNP_FW_VER_{MAJOR,MINOR} macros.
#define SEV_POLICY_NO_DBG (1UL << 0)
#define SEV_POLICY_ES (1UL << 2)
+#define SNP_POLICY_SMT (1ULL << 16)
+#define SNP_POLICY_RSVD_MBO (1ULL << 17)
+#define SNP_POLICY_DBG (1ULL << 19)
+#define SNP_POLICY (SNP_POLICY_SMT | SNP_POLICY_RSVD_MBO)
+
+#define SNP_FW_VER_MAJOR(maj) ((uint8_t)(maj) << SNP_POLICY_MAJOR_BIT)
+#define SNP_FW_VER_MINOR(min) ((uint8_t)(min) << SNP_POLICY_MINOR_BIT)
next prev parent reply other threads:[~2024-10-30 13:46 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-09-05 12:40 [PATCH v3 0/9] SEV Kernel Selftests Pratik R. Sampat
2024-09-05 12:40 ` [PATCH v3 1/9] KVM: selftests: Decouple SEV ioctls from asserts Pratik R. Sampat
2024-10-14 22:18 ` Sean Christopherson
2024-10-21 20:23 ` Pratik R. Sampat
2024-09-05 12:41 ` [PATCH v3 2/9] KVM: selftests: Add a basic SNP smoke test Pratik R. Sampat
2024-10-14 22:46 ` Sean Christopherson
2024-10-21 20:23 ` Pratik R. Sampat
2024-10-28 17:55 ` Sean Christopherson
2024-10-28 20:41 ` Pratik R. Sampat
2024-10-30 13:46 ` Sean Christopherson [this message]
2024-10-30 16:35 ` Pratik R. Sampat
2024-10-30 17:57 ` Sean Christopherson
2024-10-31 15:45 ` Pratik R. Sampat
2024-10-31 16:27 ` Sean Christopherson
2024-11-04 20:21 ` Pratik R. Sampat
2024-11-04 23:47 ` Sean Christopherson
2024-11-05 4:14 ` Pratik R. Sampat
2024-09-05 12:41 ` [PATCH v3 3/9] KVM: selftests: Add SNP to shutdown testing Pratik R. Sampat
2024-09-05 12:41 ` [PATCH v3 4/9] KVM: selftests: SEV IOCTL test Pratik R. Sampat
2024-09-05 12:41 ` [PATCH v3 5/9] KVM: selftests: SNP " Pratik R. Sampat
2024-09-05 12:41 ` [PATCH v3 6/9] KVM: selftests: SEV-SNP test for KVM_SEV_INIT2 Pratik R. Sampat
2024-09-05 12:41 ` [PATCH v3 7/9] KVM: selftests: Add interface to manually flag protected/encrypted ranges Pratik R. Sampat
2024-10-14 22:58 ` Sean Christopherson
2024-10-21 20:23 ` Pratik R. Sampat
2024-09-05 12:41 ` [PATCH v3 8/9] KVM: selftests: Add a CoCo-specific test for KVM_PRE_FAULT_MEMORY Pratik R. Sampat
2024-09-05 12:41 ` [PATCH v3 9/9] KVM: selftests: Interleave fallocate " Pratik R. Sampat
2024-10-14 22:23 ` [PATCH v3 0/9] SEV Kernel Selftests Sean Christopherson
2024-10-21 20:23 ` Pratik R. Sampat
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=ZyI4cRLsaTQ3FMk7@google.com \
--to=seanjc@google.com \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-kselftest@vger.kernel.org \
--cc=michael.roth@amd.com \
--cc=pbonzini@redhat.com \
--cc=pgonda@google.com \
--cc=pratikrajesh.sampat@amd.com \
--cc=shuah@kernel.org \
--cc=thomas.lendacky@amd.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;
as well as URLs for NNTP newsgroup(s).