Messages in this thread Patch in this message | | | Subject | Re: [PATCH v4 10/21] KVM: arm64: Support SDEI_EVENT_ROUTING_SET hypercall | From | Gavin Shan <> | Date | Wed, 12 Jan 2022 10:54:18 +0800 |
| |
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@redhat.com> >> --- >> 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
| |