From: Sean Christopherson <seanjc@google.com>
To: Ashish Kalra <ashish.kalra@amd.com>
Cc: Tom Lendacky <thomas.lendacky@amd.com>,
Peter Gonda <pgonda@google.com>,
pbonzini@redhat.com, tglx@linutronix.de, mingo@redhat.com,
bp@alien8.de, dave.hansen@linux.intel.com, hpa@zytor.com,
herbert@gondor.apana.org.au, x86@kernel.org, john.allen@amd.com,
davem@davemloft.net, michael.roth@amd.com, kvm@vger.kernel.org,
linux-kernel@vger.kernel.org, linux-crypto@vger.kernel.org
Subject: Re: [PATCH v2 3/3] x86/sev: Add SEV-SNP CipherTextHiding support
Date: Mon, 9 Dec 2024 17:30:01 -0800 [thread overview]
Message-ID: <Z1eZmXmC9oZ5RyPc@google.com> (raw)
In-Reply-To: <5b77d19d-3f34-46d7-b307-738643504cd5@amd.com>
On Fri, Dec 06, 2024, Ashish Kalra wrote:
> On 12/6/2024 4:30 PM, Sean Christopherson wrote:
> >> This can reuse the current support (in KVM) to do SEV INIT implicitly when
> >> the first SEV VM is run: sev_guest_init() -> sev_platform_init()
> >
> > I don't love the implicit behavior, but assuming hotloading firmware can't be done
> > after SEV_CMD_INIT{_EX}, that does seem like the least awful solution.
> >
> > To summarize, if the above assumptions hold:
> >
> > 1. Initialize SNP when kvm-amd.ko is loaded.
> > 2. Define CipherTextHiding and ASID params kvm-amd.ko.
> > 3. Initialize SEV+ at first use.
>
> Yes, the above summary is correct except for (3).
Heh, that wasn't a statement of fast, it was a suggestion for a possible
implementation.
> The initial set of patches will initialize SNP and SEV both at kvm-amd.ko module load,
> similar to PSP module load/probe time.
Why? If SEV+ is initialized at kvm-amd.ko load, doesn't that prevent firmware
hotloading?
> For backward compatibility, the PSP module parameter psp_init_on_probe will still be
> supported, i believe it is used for INIT_EX support.
Again, why? If the only use of psp_init_on_probe is to _disable_ that behavior,
and we make the code never init-on-probe, then the param is unnecessary, no?
> > Just to triple check: that will allow firmware hotloading even if kvm-amd.ko is
> > built-in, correct? I.e. doesn't requires deferring kvm-amd.ko load until after
> > firmware hotloading.
>
> Yes, this should work, for supporting firmware hotloading, the PSP driver's
> psp_init_on_probe parameter will need to be set to false, which will ensure
> that SEV INIT is not done during SEV/SNP platform initialization at KVM module
> probe time and instead it will be done implicitly at first SEV/SEV-ES VM launch.
Please no. I really, really don't want gunk like this in KVM:
init_args.probe = false;
ret = sev_platform_init(&init_args);
That's inscrutable without a verbose comment, and all kinds of ugly. Why can't
we simply separate SNP initialization from SEV+ initialization?
next prev parent reply other threads:[~2024-12-10 1:30 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-09-17 20:15 [PATCH v2 0/3] Add SEV-SNP CipherTextHiding feature support Ashish Kalra
2024-09-17 20:16 ` [PATCH v2 1/3] crypto: ccp: New bit-field definitions for SNP_PLATFORM_STATUS command Ashish Kalra
2024-10-01 21:40 ` Peter Gonda
2024-10-02 18:52 ` Tom Lendacky
2024-09-17 20:16 ` [PATCH v2 2/3] crypto: ccp: Add support for SNP_FEATURE_INFO command Ashish Kalra
2024-10-02 21:18 ` Tom Lendacky
2024-10-02 21:19 ` Tom Lendacky
2024-10-02 21:40 ` Kalra, Ashish
2024-10-02 21:49 ` Tom Lendacky
2024-09-17 20:16 ` [PATCH v2 3/3] x86/sev: Add SEV-SNP CipherTextHiding support Ashish Kalra
2024-10-02 14:58 ` Peter Gonda
2024-10-02 18:44 ` Kalra, Ashish
2024-10-03 14:04 ` Peter Gonda
2024-10-03 22:09 ` Ashish Kalra
2024-10-11 16:04 ` Sean Christopherson
2024-11-20 3:14 ` Kalra, Ashish
2024-11-20 21:53 ` Sean Christopherson
2024-11-20 23:43 ` Kalra, Ashish
2024-11-21 14:57 ` Kalra, Ashish
2024-11-21 16:56 ` Sean Christopherson
2024-11-21 17:24 ` Tom Lendacky
2024-11-21 17:42 ` Sean Christopherson
2024-11-21 21:00 ` Kalra, Ashish
2024-12-06 22:30 ` Sean Christopherson
2024-12-07 5:21 ` Kalra, Ashish
2024-12-10 1:30 ` Sean Christopherson [this message]
2024-12-10 21:32 ` Kalra, Ashish
2024-12-10 22:57 ` Sean Christopherson
2024-12-11 0:48 ` Kalra, Ashish
2024-12-11 1:01 ` Kalra, Ashish
2024-12-12 0:02 ` Kalra, Ashish
2024-10-02 21:46 ` Tom Lendacky
2024-10-02 21:52 ` Tom Lendacky
2024-10-11 16:10 ` Sean Christopherson
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=Z1eZmXmC9oZ5RyPc@google.com \
--to=seanjc@google.com \
--cc=ashish.kalra@amd.com \
--cc=bp@alien8.de \
--cc=dave.hansen@linux.intel.com \
--cc=davem@davemloft.net \
--cc=herbert@gondor.apana.org.au \
--cc=hpa@zytor.com \
--cc=john.allen@amd.com \
--cc=kvm@vger.kernel.org \
--cc=linux-crypto@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=michael.roth@amd.com \
--cc=mingo@redhat.com \
--cc=pbonzini@redhat.com \
--cc=pgonda@google.com \
--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.