[PATCH v3 23/27] KVM: arm64: nv: Add SVC trap forwarding

[Eric Auger]

Hi Marc,

On 8/11/23 09:36, Marc Zyngier wrote:
> On Thu, 10 Aug 2023 18:30:25 +0100,
> Eric Auger <eric.auger at redhat.com> wrote:
>> Hi Marc,
>> On 8/10/23 12:42, Marc Zyngier wrote:
>>> Hi Eric,
>>>
>>> On Thu, 10 Aug 2023 09:35:41 +0100,
>>> Eric Auger <eric.auger at redhat.com> wrote:
>>>> Hi Marc,
>>>>
>>>> On 8/8/23 13:47, Marc Zyngier wrote:
>>>>> HFGITR_EL2 allows the trap of SVC instructions to EL2. Allow these
>>>>> traps to be forwarded. Take this opportunity to deny any 32bit activity
>>>>> when NV is enabled.
>>>> I can't figure out how HFGITR_EL2.{SVC_EL1, SVC_EL0 and ERET} are
>>>> handled. Please could you explain.
>>> - SVC: KVM itself never traps it, so any trap of SVC must be the
>>>   result of a guest trap -- we don't need to do any demultiplexing. We
>>>   thus directly inject the trap back. This is what the comment in
>>>   handle_svc() tries to capture, but obviously fails to convey the
>>>   point.
>> Thank you for the explanation. Now I get it and this helps.
>>> - ERET: This is already handled since 6898a55ce38c ("KVM: arm64: nv:
>>>   Handle trapped ERET from virtual EL2"). Similarly to SVC, KVM never
>>>   traps it unless we run NV.
>> OK
>>> Now, looking into it, I think I'm missing the additional case where
>>> the L2 guest runs at vEL1. I'm about to add the following patchlet:
>>>
>>> diff --git a/arch/arm64/kvm/handle_exit.c b/arch/arm64/kvm/handle_exit.c
>>> index 3b86d534b995..617ae6dea5d5 100644
>>> --- a/arch/arm64/kvm/handle_exit.c
>>> +++ b/arch/arm64/kvm/handle_exit.c
>>> @@ -222,7 +222,22 @@ static int kvm_handle_eret(struct kvm_vcpu *vcpu)
>>>  	if (kvm_vcpu_get_esr(vcpu) & ESR_ELx_ERET_ISS_ERET)
>>>  		return kvm_handle_ptrauth(vcpu);
>>>  
>>> -	kvm_emulate_nested_eret(vcpu);
>>> +	/*
>>> +	 * If we got here, two possibilities:
>>> +	 *
>>> +	 * - the guest is in EL2, and we need to fully emulate ERET
>>> +	 *
>>> +	 * - the guest is in EL1, and we need to reinject the
>>> +         *   exception into the L1 hypervisor.
>> but in the case the guest was running in vEL1 are we supposed to trap
>> and end up here? in kvm_emulate_nested_eret I can see
>> "the current EL is always the vEL2 since we set the HCR_EL2.NV bit only
>> when entering the vEL2".
> If the guest is running at vEL1, the only ways to trap ERET are:
>
> - if the guest hypervisor has set HFGITR_EL2.ERET, because the host
>   KVM never sets that bit on its own
>
> - or if the guest hypervisor has set HCR_EL2.NV (which we don't really
>   handle so far, as we don't expose FEAT_NV to guests).
>
> If the guest is running at vEL2, then it is HCR_EL2.NV that is
> responsible for the trap, and we perform the ERET emulation.

makes sense to me. Explanation about HFGITR_EL2.ERET case is helpful and
may be worth to be added as a comment.
>
>> But I am still catching up on the already landed
>>
>> [PATCH 00/18] KVM: arm64: Prefix patches for NV support
>> <https://lore.kernel.org/all/20230209175820.1939006-1-maz@kernel.org/>
>> so please forgive me my confusion ;-)
> Confusion is the whole purpose of NV, so don't worry, you're in good
> company here! :D
:-)

Eric
>
> Thanks,
>
> 	M.
>