| Message ID | 20210510134824.1910399-3-maz@kernel.org (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | KVM: arm64: Initial host support for the Apple M1 | expand |
Hi Marc, On 5/10/21 2:48 PM, Marc Zyngier wrote: > As we we now entertain the possibility of FIQ being used on the host, > treat the signalling of a FIQ while running a guest as an IRQ, > causing an exit instead of a HYP panic. I've mulling over this, and I can't find anything wrong with it. Any FIQs for which there is no handler registered by the interrupt controller will panic in the default_handle_fiq() FIQ handler, similar to the current KVM behaviour. And if there is a handler registered (only AIC does it for now), then a FIQ will be handled just like any other interrupt instead of KVM panic'ing when the host can handle it just fine. I've briefly considered creating a new return code from __kvm_vcpu_run, ARM_EXCEPTION_FIQ, but I really don't see any reason for it, since it will serve the same purpose as ARM_EXCEPTION_IRQ, which is to resume the guest without any special exit handling. It makes sense to me for KVM to handle FIQs just like IRQs, now that the kernel treats them the same: Reviewed-by: Alexandru Elisei <alexandru.elisei@arm.com> Thanks, Alex > > Signed-off-by: Marc Zyngier <maz@kernel.org> > --- > arch/arm64/kvm/hyp/hyp-entry.S | 6 +++--- > 1 file changed, 3 insertions(+), 3 deletions(-) > > diff --git a/arch/arm64/kvm/hyp/hyp-entry.S b/arch/arm64/kvm/hyp/hyp-entry.S > index 5f49df4ffdd8..9aa9b73475c9 100644 > --- a/arch/arm64/kvm/hyp/hyp-entry.S > +++ b/arch/arm64/kvm/hyp/hyp-entry.S > @@ -76,6 +76,7 @@ el1_trap: > b __guest_exit > > el1_irq: > +el1_fiq: > get_vcpu_ptr x1, x0 > mov x0, #ARM_EXCEPTION_IRQ > b __guest_exit > @@ -131,7 +132,6 @@ SYM_CODE_END(\label) > invalid_vector el2t_error_invalid > invalid_vector el2h_irq_invalid > invalid_vector el2h_fiq_invalid > - invalid_vector el1_fiq_invalid > > .ltorg > > @@ -179,12 +179,12 @@ SYM_CODE_START(__kvm_hyp_vector) > > valid_vect el1_sync // Synchronous 64-bit EL1 > valid_vect el1_irq // IRQ 64-bit EL1 > - invalid_vect el1_fiq_invalid // FIQ 64-bit EL1 > + valid_vect el1_fiq // FIQ 64-bit EL1 > valid_vect el1_error // Error 64-bit EL1 > > valid_vect el1_sync // Synchronous 32-bit EL1 > valid_vect el1_irq // IRQ 32-bit EL1 > - invalid_vect el1_fiq_invalid // FIQ 32-bit EL1 > + valid_vect el1_fiq // FIQ 32-bit EL1 > valid_vect el1_error // Error 32-bit EL1 > SYM_CODE_END(__kvm_hyp_vector) >
diff --git a/arch/arm64/kvm/hyp/hyp-entry.S b/arch/arm64/kvm/hyp/hyp-entry.S index 5f49df4ffdd8..9aa9b73475c9 100644 --- a/arch/arm64/kvm/hyp/hyp-entry.S +++ b/arch/arm64/kvm/hyp/hyp-entry.S @@ -76,6 +76,7 @@ el1_trap: b __guest_exit el1_irq: +el1_fiq: get_vcpu_ptr x1, x0 mov x0, #ARM_EXCEPTION_IRQ b __guest_exit @@ -131,7 +132,6 @@ SYM_CODE_END(\label) invalid_vector el2t_error_invalid invalid_vector el2h_irq_invalid invalid_vector el2h_fiq_invalid - invalid_vector el1_fiq_invalid .ltorg @@ -179,12 +179,12 @@ SYM_CODE_START(__kvm_hyp_vector) valid_vect el1_sync // Synchronous 64-bit EL1 valid_vect el1_irq // IRQ 64-bit EL1 - invalid_vect el1_fiq_invalid // FIQ 64-bit EL1 + valid_vect el1_fiq // FIQ 64-bit EL1 valid_vect el1_error // Error 64-bit EL1 valid_vect el1_sync // Synchronous 32-bit EL1 valid_vect el1_irq // IRQ 32-bit EL1 - invalid_vect el1_fiq_invalid // FIQ 32-bit EL1 + valid_vect el1_fiq // FIQ 32-bit EL1 valid_vect el1_error // Error 32-bit EL1 SYM_CODE_END(__kvm_hyp_vector)
As we we now entertain the possibility of FIQ being used on the host, treat the signalling of a FIQ while running a guest as an IRQ, causing an exit instead of a HYP panic. Signed-off-by: Marc Zyngier <maz@kernel.org> --- arch/arm64/kvm/hyp/hyp-entry.S | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-)