lkml.org 
[lkml]   [2022]   [Jan]   [11]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
Patch in this message
/
SubjectRe: [PATCH v4 10/21] KVM: arm64: Support SDEI_EVENT_ROUTING_SET hypercall
From
Date
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

\
 
 \ /
  Last update: 2022-01-12 03:55    [W:0.167 / U:0.104 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site