On 8/19/24 5:23 PM, Sean Christopherson wrote:
On Mon, Aug 19, 2024, Kim Phillips wrote:
On 8/16/24 5:59 PM, Sean Christopherson wrote:
On Thu, Aug 01, 2024, Kim Phillips wrote:
From: Kishon Vijay Abraham I <kvijayab@xxxxxxx>
AMD EPYC 5th generation processors have introduced a feature that allows
the hypervisor to control the SEV_FEATURES that are set for or by a
guest [1]. The ALLOWED_SEV_FEATURES feature can be used by the hypervisor
to enforce that SEV-ES and SEV-SNP guests cannot enable features that the
hypervisor does not want to be enabled.
How does the host communicate to the guest which features are allowed?
I'm not familiar with any future plans to negotiate with the guest directly,
I feel like I'm missing something. What happens if the guest wants to enable
PmcVirtualization and it's unexpectedly disallowed? Does the guest simply panic?
In SNP, VMRUN will return with an exit code of VMEXIT_INVALID (0xffffffff)
if the guest tries to set it.
In SEV-ES, the hypervisor can set it, and the same thing will happen to VMRUN.
In both cases, SEV_FEATURES is saved to VMCB field GUEST_SEV_FEATURES at
offset 140h on the VMEXIT, indicating to the host which feature was
attempted but caught as not allowed.
but since commit ac5c48027bac ("KVM: SEV: publish supported VMSA features"),
userspace can retrieve sev_supported_vmsa_features via an ioctl.
And based on this blurb:
Some SEV features can only be used if the Allowed SEV Features Mask is enabled,
and the mask is configured to permit the corresponding feature. If the Allowed
SEV Features Mask is not enabled, these features are not available (see SEV_FEATURES
in Appendix B, Table B-4).
and the appendix, this only applies to PmcVirtualization and SecureAvic. Adding
that info in the changelog would be *very* helpful.
Ok, how about adding:
"The PmcVirtualization and SecureAvic features explicitly require
ALLOWED_SEV_FEATURES to enable them before they can be used."
And I see that SVM_SEV_FEAT_DEBUG_SWAP, a.k.a. DebugVirtualization, is a guest
controlled feature and doesn't honor ALLOWED_SEV_FEATURES. Doesn't that mean
sev_vcpu_has_debug_swap() is broken, i.e. that KVM must assume the guest can
DebugVirtualization on and off at will? Or am I missing something?
My understanding is that users control KVM's DEBUG_SWAP setting
with a module parameter since commit 4dd5ecacb9a4 ("KVM: SEV: allow
SEV-ES DebugSwap again"). If the module parameter is not set, with
this patch, VMRUN will fail since the host doesn't allow DEBUG_SWAP.
But that's just KVM's view of vmsa_features. With SNP's wonderful
SVM_VMGEXIT_AP_CREATE, can't the guest create a VMSA with whatever sev_features
it wants, so long as they aren't host-controllable, i.e. aren't PmcVirtualization
or SecureAvic?
No, as above, if the guest tries any silly business the host will
get a VMEXIT_INVALID, no matter if using the feature *requires*
ALLOWED_SEV_FEATURES to be enabled and explicitly allow it (currently
PmcVirtualization or SecureAvic).
Kim
