linux-kernel - Re: [PATCH v5 15/22] KVM: arm64: Support SDEI_EVENT

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <cfd58d73-ada1-8c42-1d3e-794766dd86d5@redhat.com>
Date:   Wed, 23 Mar 2022 20:52:15 +0800
From:   Gavin Shan <gshan@...hat.com>
To:     Oliver Upton <oupton@...gle.com>
Cc:     kvmarm@...ts.cs.columbia.edu, maz@...nel.org,
        linux-kernel@...r.kernel.org, eauger@...hat.com,
        shan.gavin@...il.com, Jonathan.Cameron@...wei.com,
        pbonzini@...hat.com, vkuznets@...hat.com, will@...nel.org
Subject: Re: [PATCH v5 15/22] KVM: arm64: Support SDEI_EVENT_SIGNAL hypercall

Hi Oliver,

On 3/23/22 7:06 AM, Oliver Upton wrote:
> On Tue, Mar 22, 2022 at 04:07:03PM +0800, Gavin Shan wrote:
>> This supports SDEI_EVENT_SIGNAL hypercall. It's used by the guest
>> to inject SDEI event, whose number must be zero to the specified
>> vCPU. As the routing mode and affinity isn't supported yet, the
>> calling vCPU is assumed to be the target.
>>
>> The SDEI event 0x0 is a private one, with normal priority. It's
>> usually used for testing.
> 
> I don't know if that is actually the case. One real use that immediately
> comes to mind is doing an NMI on a wedged CPU. KVM probably shouldn't
> glean at how the guest may use a particular call, so at most we should
> just point at the spec and state that event 0 is for software signaled
> events.
> 

Yes, I agree. I will amend the change log in next respin, to make it
clear. As you said, it really depend on how the event is used by
the guest. We can't assume its usage.

>> Signed-off-by: Gavin Shan <gshan@...hat.com>
>> ---
>>   arch/arm64/kvm/sdei.c | 64 ++++++++++++++++++++++++++++++++++++++++++-
>>   1 file changed, 63 insertions(+), 1 deletion(-)
>>
>> diff --git a/arch/arm64/kvm/sdei.c b/arch/arm64/kvm/sdei.c
>> index a24270378305..ba2ca65c871b 100644
>> --- a/arch/arm64/kvm/sdei.c
>> +++ b/arch/arm64/kvm/sdei.c
>> @@ -726,6 +726,66 @@ static int do_inject_event(struct kvm_vcpu *vcpu,
>>   	return 0;
>>   }
>>   
>> +static unsigned long hypercall_signal(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_exposed_event *exposed_event;
>> +	struct kvm_sdei_registered_event *registered_event;
>> +	unsigned long event_num = smccc_get_arg1(vcpu);
>> +	int index;
>> +	unsigned long ret = SDEI_SUCCESS;
>> +
>> +	/* @event_num must be zero */
>> +	if (!kvm_sdei_is_default(event_num)) {
> 
> 0 isn't KVM's default event. I'd argue KVM doesn't have a default event
> to begin with. This has a precise definition coming from the spec. In
> fact, 'KVM_SDEI_DEFAULT_EVENT' should probably be eliminated, and any
> missing SDEI definitions should be added to include/uapi/linux/arm_sdei.h.
> 
> That goes for any values coming from the specification. KVM's
> implementation details belong in a KVM header :)
> 

Indeed. include/uapi/linux/arm_sdei.h is the right place to define
the software signaled event number. The function to validate/check
on it is still part of kvm_sdei.h, but its name would be something
like kvm_sdei_is_sw_signaled() or kvm_sdei_is_signaled_event().

Thanks,
Gavin