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
