[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH RFC for-4.13 03/10] xen/arm: traps: Rework entry/exit from the guest path
On Thu, 26 Sep 2019, Julien Grall wrote: > At the moment, enter_hypervisor_head() and leave_hypervisor_tail() are > used to deal with actions to be done before/after any guest request is > handled. > > While they are meant to work in pair, the former is called for most of > the traps, including traps from the same exception level (i.e. > hypervisor) whilst the latter will only be called when returning to the > guest. > > As pointed out, the enter_hypervisor_head() is not called from all the > traps, so this makes potentially difficult to extend it for the dealing > with same exception level. > > Furthermore, some assembly only path will require to call > enter_hypervisor_tail(). So the function is now directly call by > assembly in for guest vector only. This means that the check whether we > are called in a guest trap can now be removed. > > Take the opportunity to rename enter_hypervisor_tail() and > leave_hypervisor_tail() to something more meaningful and document them. > This should help everyone to understand the purpose of the two > functions. > > Signed-off-by: Julien Grall <julien.grall@xxxxxxx> > > --- > > I haven't done the 32-bits part yet. I wanted to gather feedback before > looking in details how to integrate that with Arm32. > --- > xen/arch/arm/arm64/entry.S | 4 ++- > xen/arch/arm/traps.c | 71 > ++++++++++++++++++++++------------------------ > 2 files changed, 37 insertions(+), 38 deletions(-) > > diff --git a/xen/arch/arm/arm64/entry.S b/xen/arch/arm/arm64/entry.S > index 40d9f3ec8c..9eafae516b 100644 > --- a/xen/arch/arm/arm64/entry.S > +++ b/xen/arch/arm/arm64/entry.S > @@ -147,7 +147,7 @@ > > .if \hyp == 0 /* Guest mode */ > > - bl leave_hypervisor_tail /* Disables interrupts on return */ > + bl leave_hypervisor_to_guest /* Disables interrupts on return */ > > exit_guest \compat > > @@ -175,6 +175,8 @@ > SKIP_SYNCHRONIZE_SERROR_ENTRY_EXIT) > msr daifclr, \iflags > mov x0, sp > + bl enter_hypervisor_from_guest > + mov x0, sp > bl do_trap_\trap > 1: > exit hyp=0, compat=\compat > diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c > index a3b961bd06..20ba34ec91 100644 > --- a/xen/arch/arm/traps.c > +++ b/xen/arch/arm/traps.c > @@ -2006,47 +2006,46 @@ static inline bool needs_ssbd_flip(struct vcpu *v) > cpu_require_ssbd_mitigation(); > } > > -static void enter_hypervisor_head(struct cpu_user_regs *regs) > +/* > + * Actions that needs to be done after exiting the guest and before any > + * request from it is handled. > + */ > +void enter_hypervisor_from_guest(struct cpu_user_regs *regs) > { > - if ( guest_mode(regs) ) > - { > - struct vcpu *v = current; > + struct vcpu *v = current; > > - /* If the guest has disabled the workaround, bring it back on. */ > - if ( needs_ssbd_flip(v) ) > - arm_smccc_1_1_smc(ARM_SMCCC_ARCH_WORKAROUND_2_FID, 1, NULL); > + /* If the guest has disabled the workaround, bring it back on. */ > + if ( needs_ssbd_flip(v) ) > + arm_smccc_1_1_smc(ARM_SMCCC_ARCH_WORKAROUND_2_FID, 1, NULL); > > - /* > - * If we pended a virtual abort, preserve it until it gets cleared. > - * See ARM ARM DDI 0487A.j D1.14.3 (Virtual Interrupts) for details, > - * but the crucial bit is "On taking a vSError interrupt, HCR_EL2.VSE > - * (alias of HCR.VA) is cleared to 0." > - */ > - if ( v->arch.hcr_el2 & HCR_VA ) > - v->arch.hcr_el2 = READ_SYSREG(HCR_EL2); > + /* > + * If we pended a virtual abort, preserve it until it gets cleared. > + * See ARM ARM DDI 0487A.j D1.14.3 (Virtual Interrupts) for details, > + * but the crucial bit is "On taking a vSError interrupt, HCR_EL2.VSE > + * (alias of HCR.VA) is cleared to 0." > + */ > + if ( v->arch.hcr_el2 & HCR_VA ) > + v->arch.hcr_el2 = READ_SYSREG(HCR_EL2); > > #ifdef CONFIG_NEW_VGIC > - /* > - * We need to update the state of our emulated devices using level > - * triggered interrupts before syncing back the VGIC state. > - * > - * TODO: Investigate whether this is necessary to do on every > - * trap and how it can be optimised. > - */ > - vtimer_update_irqs(v); > - vcpu_update_evtchn_irq(v); > + /* > + * We need to update the state of our emulated devices using level > + * triggered interrupts before syncing back the VGIC state. > + * > + * TODO: Investigate whether this is necessary to do on every > + * trap and how it can be optimised. > + */ > + vtimer_update_irqs(v); > + vcpu_update_evtchn_irq(v); > #endif > > - vgic_sync_from_lrs(v); > - } > + vgic_sync_from_lrs(v); > } > > void do_trap_guest_sync(struct cpu_user_regs *regs) > { > const union hsr hsr = { .bits = regs->hsr }; > > - enter_hypervisor_head(regs); > - > switch ( hsr.ec ) > { > case HSR_EC_WFI_WFE: > @@ -2180,8 +2179,6 @@ void do_trap_hyp_sync(struct cpu_user_regs *regs) > { > const union hsr hsr = { .bits = regs->hsr }; > > - enter_hypervisor_head(regs); > - > switch ( hsr.ec ) > { > #ifdef CONFIG_ARM_64 > @@ -2218,27 +2215,21 @@ void do_trap_hyp_sync(struct cpu_user_regs *regs) > > void do_trap_hyp_serror(struct cpu_user_regs *regs) > { > - enter_hypervisor_head(regs); > - > __do_trap_serror(regs, VABORT_GEN_BY_GUEST(regs)); > } > > void do_trap_guest_serror(struct cpu_user_regs *regs) > { > - enter_hypervisor_head(regs); > - > __do_trap_serror(regs, true); > } > > void do_trap_irq(struct cpu_user_regs *regs) > { > - enter_hypervisor_head(regs); > gic_interrupt(regs, 0); > } > > void do_trap_fiq(struct cpu_user_regs *regs) > { > - enter_hypervisor_head(regs); > gic_interrupt(regs, 1); > } I am OK with the general approach but one thing to note is that the fiq handler doesn't use the guest_vector macro at the moment. > @@ -2281,7 +2272,13 @@ static void check_for_vcpu_work(void) > local_irq_disable(); > } > > -void leave_hypervisor_tail(void) > +/* > + * Actions that needs to be done before entering the guest. This is the > + * last thing executed before the guest context is fully restored. > + * > + * The function will return with interrupts disabled. > + */ > +void leave_hypervisor_to_guest(void) > { > local_irq_disable(); > > -- > 2.11.0 > _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxxx https://lists.xenproject.org/mailman/listinfo/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |