Hi Eric,
On 11/10/21 2:47 AM, Eric Auger wrote:
On 8/15/21 2:13 AM, Gavin Shan wrote:
This supports SDEI_EVENT_ROUTING_SET hypercall. It's used by the
guest to set route mode and affinity for the registered KVM event.
It's only valid for the shared events. It's not allowed to do so
when the corresponding event has been raised to the guest.
Signed-off-by: Gavin Shan <gshan@xxxxxxxxxx>
---
arch/arm64/kvm/sdei.c | 64 +++++++++++++++++++++++++++++++++++++++++++
1 file changed, 64 insertions(+)
diff --git a/arch/arm64/kvm/sdei.c b/arch/arm64/kvm/sdei.c
index 5dfa74b093f1..458695c2394f 100644
--- a/arch/arm64/kvm/sdei.c
+++ b/arch/arm64/kvm/sdei.c
@@ -489,6 +489,68 @@ static unsigned long kvm_sdei_hypercall_info(struct kvm_vcpu *vcpu)
return ret;
}
+static unsigned long kvm_sdei_hypercall_route(struct kvm_vcpu *vcpu)
+{
+ 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);
+ unsigned long route_mode = smccc_get_arg2(vcpu);
+ unsigned long route_affinity = smccc_get_arg3(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)) {
+ ret = SDEI_INVALID_PARAMETERS;
+ goto out;
+ }
+
+ if (!(route_mode == SDEI_EVENT_REGISTER_RM_ANY ||
+ route_mode == SDEI_EVENT_REGISTER_RM_PE)) {
+ ret = SDEI_INVALID_PARAMETERS;
+ goto out;
+ }
Some sanity checking on the affinity arg could be made as well according
to 5.1.2 affinity desc. The fn shall return INVALID_PARAMETER in case
of invalid affinity.
Yep, you're right. I didn't figure out it. I may put a comment here.
For now, the SDEI client driver in the guest kernel doesn't attempt
to change the routing mode.
/* FIXME: The affinity should be verified */
+
+ /* Check if the KVM event has been registered */
+ spin_lock(&ksdei->lock);
+ kske = kvm_sdei_find_kvm_event(kvm, event_num);
+ if (!kske) {
+ ret = SDEI_INVALID_PARAMETERS;
+ goto unlock;
+ }
+
+ /* Validate KVM event state */
+ kse = kske->kse;
+ if (kse->state.type != SDEI_EVENT_TYPE_SHARED) {
+ ret = SDEI_INVALID_PARAMETERS;
+ goto unlock;
+ }
+
Event handler is in a state other than: handler-registered.
They're equivalent as the handler is provided as a parameter when
the event is registered.
+ if (!kvm_sdei_is_registered(kske, index) ||
+ kvm_sdei_is_enabled(kske, index) ||
+ kske->state.refcount) {
I am not sure about the refcount role here. Does it make sure the state
is != handler-enabled and running or handler-unregister-pending?
I think we would gain in readibility if we had a helper to check whether
we are in those states?
@refcount here indicates pending SDEI event for delivery. In this case,
chaning its routing mode is disallowed.
+ ret = SDEI_DENIED;
+ goto unlock;
+ }
+
+ /* Update state */
+ kske->state.route_mode = route_mode;
+ kske->state.route_affinity = route_affinity;
+
+unlock:
+ spin_unlock(&ksdei->lock);
+out:
+ return ret;
+}
+
int kvm_sdei_hypercall(struct kvm_vcpu *vcpu)
{
u32 func = smccc_get_function(vcpu);
@@ -523,6 +585,8 @@ int kvm_sdei_hypercall(struct kvm_vcpu *vcpu)
ret = kvm_sdei_hypercall_info(vcpu);
break;
case SDEI_1_0_FN_SDEI_EVENT_ROUTING_SET:
+ ret = kvm_sdei_hypercall_route(vcpu);
+ break;
case SDEI_1_0_FN_SDEI_PE_MASK:
case SDEI_1_0_FN_SDEI_PE_UNMASK:
case SDEI_1_0_FN_SDEI_INTERRUPT_BIND:
Thanks,
Gavin
_______________________________________________
kvmarm mailing list
kvmarm@xxxxxxxxxxxxxxxxxxxxx
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
