Re: [PATCH v4 05/21] KVM: arm64: Support SDEI_EVENT_{ENABLE, DISABLE} hypercall

From: Gavin Shan
Date: Tue Jan 11 2022 - 21:29:30 EST


Hi Eric,

On 11/10/21 12:02 AM, Eric Auger wrote:
On 8/15/21 2:13 AM, Gavin Shan wrote:
This supports SDEI_EVENT_{ENABLE, DISABLE} hypercall. After SDEI
event is registered by guest, it won't be delivered to the guest
until it's enabled. On the other hand, the SDEI event won't be
raised to the guest or specific vCPU if it's has been disabled
on the guest or specific vCPU.

Signed-off-by: Gavin Shan <gshan@xxxxxxxxxx>
---
arch/arm64/kvm/sdei.c | 68 +++++++++++++++++++++++++++++++++++++++++++
1 file changed, 68 insertions(+)

diff --git a/arch/arm64/kvm/sdei.c b/arch/arm64/kvm/sdei.c
index d3ea3eee154b..b022ce0a202b 100644
--- a/arch/arm64/kvm/sdei.c
+++ b/arch/arm64/kvm/sdei.c
@@ -206,6 +206,70 @@ static unsigned long kvm_sdei_hypercall_register(struct kvm_vcpu *vcpu)
return ret;
}
+static unsigned long kvm_sdei_hypercall_enable(struct kvm_vcpu *vcpu,
+ bool enable)
+{
+ struct kvm *kvm = vcpu->kvm;
+ struct kvm_sdei_kvm *ksdei = kvm->arch.sdei;
+ struct kvm_sdei_vcpu *vsdei = vcpu->arch.sdei;
+ struct kvm_sdei_event *kse = NULL;
+ struct kvm_sdei_kvm_event *kske = NULL;
+ unsigned long event_num = smccc_get_arg1(vcpu);
+ int index = 0;
+ unsigned long ret = SDEI_SUCCESS;
+
+ /* Sanity check */
+ if (!(ksdei && vsdei)) {
+ ret = SDEI_NOT_SUPPORTED;
+ goto out;
+ }
+
+ if (!kvm_sdei_is_valid_event_num(event_num)) {
I would rename into is_exposed_event_num()

kvm_sdei_is_virtual() has been recommended by you when you reviewed the following
patch. I think kvm_sdei_is_virtual() is good enough :)

[PATCH v4 02/21] KVM: arm64: Add SDEI virtualization infrastructure

+ ret = SDEI_INVALID_PARAMETERS;
+ goto out;
+ }
+
+ /* Check if the KVM event exists */
+ spin_lock(&ksdei->lock);
+ kske = kvm_sdei_find_kvm_event(kvm, event_num);
+ if (!kske) {
+ ret = SDEI_INVALID_PARAMETERS;
should be DENIED according to the spec, ie. nobody registered that event?

Ok.

+ goto unlock;
+ }
+
+ /* Check if there is pending events */
does that match the "handler-unregister-pending state" case mentionned
in the spec?
+ if (kske->state.refcount) {
+ ret = SDEI_PENDING;
? not documented in my A spec? DENIED?

Yep, It should be DENIED.

+ goto unlock;
+ }
+
+ /* Check if it has been registered */
isn't duplicate of /* Check if the KVM event exists */ ?

It's not duplicate check, but the comment here seems misleading. I will
correct this to:

/* Check if it has been defined or exposed */

+ kse = kske->kse;
+ index = (kse->state.type == SDEI_EVENT_TYPE_PRIVATE) ?
+ vcpu->vcpu_idx : 0;
+ if (!kvm_sdei_is_registered(kske, index)) {
+ ret = SDEI_DENIED;
+ goto unlock;
+ }
+
+ /* Verify its enablement state */
+ if (enable == kvm_sdei_is_enabled(kske, index)) {
spec says:
Enabling/disabled an event, which is already enabled/disabled, is
permitted and has no effect. I guess ret should be OK.

yep, it should be ok.

+ ret = SDEI_DENIED;
+ goto unlock;
+ }
+
+ /* Update enablement state */
+ if (enable)
+ kvm_sdei_set_enabled(kske, index);
+ else
+ kvm_sdei_clear_enabled(kske, index);
+
+unlock:
+ spin_unlock(&ksdei->lock);
+out:
+ return ret;
+}
+
int kvm_sdei_hypercall(struct kvm_vcpu *vcpu)
{
u32 func = smccc_get_function(vcpu);
@@ -220,7 +284,11 @@ int kvm_sdei_hypercall(struct kvm_vcpu *vcpu)
ret = kvm_sdei_hypercall_register(vcpu);
break;
case SDEI_1_0_FN_SDEI_EVENT_ENABLE:
+ ret = kvm_sdei_hypercall_enable(vcpu, true);
+ break;
case SDEI_1_0_FN_SDEI_EVENT_DISABLE:
+ ret = kvm_sdei_hypercall_enable(vcpu, false);
+ break;
case SDEI_1_0_FN_SDEI_EVENT_CONTEXT:
case SDEI_1_0_FN_SDEI_EVENT_COMPLETE:
case SDEI_1_0_FN_SDEI_EVENT_COMPLETE_AND_RESUME:


Thanks,
Gavin