Re: [PATCH Part2 RFC v4 40/40] KVM: SVM: Support SEV-SNP AP Creation NAE event

[Tom Lendacky]

On 7/21/21 2:52 PM, Sean Christopherson wrote:
> On Wed, Jul 21, 2021, Tom Lendacky wrote:
> > On 7/20/21 7:01 PM, Sean Christopherson wrote:
> > > On Wed, Jul 07, 2021, Brijesh Singh wrote:
> > > > From: Tom Lendacky <thomas.lendacky@xxxxxxx>
...
> > > This seems like it's missing a big pile of sanity checks.  E.g. KVM should reject
> > > SVM_VMGEXIT_AP_CREATE if the target vCPU is already "created", including the case
> > > where it was "created_on_init" but hasn't yet received INIT-SIPI.
> >
> > Why? If the guest wants to call it multiple times I guess I don't see a
> > reason that it would need to call DESTROY first and then CREATE. I don't
> > know why a guest would want to do that, but I don't think we should
> > prevent it.
>
> Because "creating" a vCPU that already exists is non-sensical.  Ditto for

Maybe the names of CREATE and DESTROY weren't the best choice. The intent 
is to replace INIT-SIPI.

> onlining a vCPU that is already onlined.  E.g. from the guest's perspective, I
> would fully expect a SVM_VMGEXIT_AP_CREATE to fail, not effectively send the vCPU
> to an arbitrary state.

The GHCB document does not require thos. To accomplish the same thing that 
a CREATE does today, the guest does DESTROY followed by CREATE. What's the 
difference, the DESTROY will kick the vCPU out and make it non-runnable 
and the guest will immediately follow that with a CREATE and set the new 
state. All of which can be accomplished by just calling CREATE to begin 
with - the net is the same, the vCPU gets taken from one state to a new state.

> Any ambiguity as to the legality of CREATE/DESTROY absolutely needs to be clarified
> in the GHCB.

I don't see any ambiguity. The document states when the VMSA becomes 
effective and there's no requirement/need to issue a DESTROY before 
another CREATE.

> > > > +
> > > > +	target_svm->snp_vmsa_gpa = 0;
> > > > +	target_svm->snp_vmsa_update_on_init = false;
> > > > +
> > > > +	/* Interrupt injection mode shouldn't change for AP creation */
> > > > +	if (request < SVM_VMGEXIT_AP_DESTROY) {
> > > > +		u64 sev_features;
> > > > +
> > > > +		sev_features = vcpu->arch.regs[VCPU_REGS_RAX];
> > > > +		sev_features ^= sev->sev_features;
> > > > +		if (sev_features & SVM_SEV_FEATURES_INT_INJ_MODES) {
> > >
> > > Why is only INT_INJ_MODES checked?  The new comment in sev_es_sync_vmsa() explicitly
> > > states that sev_features are the same for all vCPUs, but that's not enforced here.
> > > At a bare minimum I would expect this to sanity check SVM_SEV_FEATURES_SNP_ACTIVE.
> >
> > That's because we can't really enforce it. The SEV_FEATURES value is part
> > of the VMSA, of which the hypervisor has no insight into (its encrypted).
> >
> > The interrupt injection mechanism was specifically requested as a sanity
> > check type of thing during the GHCB review, and as there were no
> > objections, it was added (see the end of section 4.1.9).
> >
> > I can definitely add the check for the SNP_ACTIVE bit, but it isn't required.
>
> I'm confused.  If we've no insight into what the guest is actually using, what's
> the point of the INT_INJ_MODES check?

As I said, it was requested and there were no objections, all with the 
knowledge that the guest could "lie" about it. Maybe it is just to ensure 
the proper behavior of an "honest" guest? It makes for a small bit of 
extra work, but, yes, isn't very useful from a KVM perspective.

Thanks,
Tom

>