All of lore.kernel.org
 help / color / mirror / Atom feed
From: Julien Grall <Julien.Grall@arm.com>
To: Stefano Stabellini <sstabellini@kernel.org>
Cc: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>,
	Andre Przywara <Andre.Przywara@arm.com>, nd <nd@arm.com>,
	Volodymyr Babchuk <Volodymyr_Babchuk@epam.com>,
	"andrii.anisov@gmail.com" <andrii.anisov@gmail.com>
Subject: Re: [Xen-devel] [PATCH RFC for-4.13 03/10] xen/arm: traps: Rework entry/exit from the guest path
Date: Tue, 1 Oct 2019 21:06:21 +0000	[thread overview]
Message-ID: <af8c7f32-699b-7611-495b-575a81361952@arm.com> (raw)
In-Reply-To: <alpine.DEB.2.21.1910011312180.20899@sstabellini-ThinkPad-T480s>

Hi,

On 01/10/2019 21:12, Stefano Stabellini wrote:
> 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@arm.com>
>>
>> ---
>>
>> 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.

do_trap_fiq() is not called from arm64 Instead, we call do_bad_mode(). 
So I don't see an issue here.

As do_bad_mode() does not call enter_hypervisor_head(), the fiq handler 
does not use guest_vector.

That said, it is interesting to see that we don't deal the same way the 
FIQ on Arm32 and Arm64. On the former, we will call do_IRQ while the 
latter will crash the guest.

It would be good if we can have the same behavior accross the two arch 
if possible. I vaguely recall someone (Andre?) mentioning some changes 
around FIQ in KVM recently. Andre, are FIQ meant to work with Guest?

Also, a side effect of not calling enter_hypervisor_head() is workaround 
are not re-enabled. We are going to panic soon after, so it may not be 
that much an issue.

I will have a think about it.

Cheers,

-- 
Julien Grall
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

  reply	other threads:[~2019-10-01 21:07 UTC|newest]

Thread overview: 62+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-09-26 18:37 [Xen-devel] [PATCH RFC for-4.13 00/10] xen/arm: XSA-201 and XSA-263 fixes Julien Grall
2019-09-26 18:37 ` [Xen-devel] [PATCH RFC for-4.13 01/10] xen/arm64: entry: Introduce a macro to generate guest vector and use it Julien Grall
2019-09-27 11:34   ` Volodymyr Babchuk
2019-10-01 19:53     ` Stefano Stabellini
2019-09-26 18:38 ` [Xen-devel] [PATCH RFC for-4.13 02/10] xen/arm64: head: Check if an SError is pending when receiving a vSError Julien Grall
2019-09-27 11:35   ` Volodymyr Babchuk
2019-10-01 19:58     ` Stefano Stabellini
2019-09-26 18:38 ` [Xen-devel] [PATCH RFC for-4.13 03/10] xen/arm: traps: Rework entry/exit from the guest path Julien Grall
2019-09-27 11:45   ` Volodymyr Babchuk
2019-09-27 12:16     ` Julien Grall
2019-09-27 12:27       ` Volodymyr Babchuk
2019-09-27 12:44         ` Julien Grall
2019-09-27 12:49           ` Volodymyr Babchuk
2019-10-01 20:12   ` Stefano Stabellini
2019-10-01 21:06     ` Julien Grall [this message]
2019-10-02  0:16       ` Stefano Stabellini
2019-10-02  9:12         ` Julien Grall
2019-10-02 12:41         ` Stefano Stabellini
2019-10-02 12:47           ` Julien Grall
2019-10-02 22:26             ` Stefano Stabellini
2019-10-03 10:24               ` Julien Grall
2019-10-03 17:48                 ` Stefano Stabellini
2019-10-03 17:53                   ` Julien Grall
2019-09-26 18:38 ` [Xen-devel] [PATCH RFC for-4.13 04/10] xen/arm: Ensure the SSBD workaround is re-enabled right after exiting a guest Julien Grall
2019-09-27 11:56   ` Volodymyr Babchuk
2019-09-27 12:22     ` Julien Grall
2019-09-27 12:39       ` Volodymyr Babchuk
2019-09-27 13:16         ` Julien Grall
2019-09-27 13:33           ` Volodymyr Babchuk
2019-09-27 14:11             ` Julien Grall
2019-09-27 14:21               ` Volodymyr Babchuk
2019-09-27 16:24                 ` Julien Grall
2019-09-27 17:58                   ` Volodymyr Babchuk
2019-09-27 20:31                     ` Julien Grall
2019-09-30 12:14   ` Volodymyr Babchuk
2019-09-30 12:15     ` Julien Grall
2019-09-26 18:38 ` [Xen-devel] [PATCH RFC for-4.13 05/10] xen/arm: alternative: Remove unused parameter for alternative_if_not_cap Julien Grall
2019-09-27 11:50   ` Volodymyr Babchuk
2019-10-01 20:55     ` Stefano Stabellini
2019-09-26 18:38 ` [Xen-devel] [PATCH RFC for-4.13 06/10] xen/arm: Move ARCH_PATCH_INSN_SIZE out of the header livepatch.h Julien Grall
2019-09-27 11:51   ` Volodymyr Babchuk
2019-09-27 11:59   ` Ross Lagerwall
2019-10-01 20:57   ` Stefano Stabellini
2019-09-26 18:38 ` [Xen-devel] [PATCH RFC for-4.13 07/10] xen/arm: Allow insn.h to be called from assembly Julien Grall
2019-09-27 11:52   ` Volodymyr Babchuk
2019-10-01 21:00   ` Stefano Stabellini
2019-10-21 16:43     ` Julien Grall
2019-10-21 17:23       ` Stefano Stabellini
2019-09-26 18:38 ` [Xen-devel] [PATCH RFC for-4.13 08/10] xen/arm: alternative: add auto-nop infrastructure Julien Grall
2019-09-27 15:34   ` Volodymyr Babchuk
2019-10-01 22:08     ` Stefano Stabellini
2019-09-26 18:38 ` [Xen-devel] [PATCH RFC for-4.13 09/10] xen/arm: asm: Replace use of ALTERNATIVE with alternative_if Julien Grall
2019-09-27 12:11   ` Volodymyr Babchuk
2019-09-27 12:34     ` Julien Grall
2019-09-27 12:46       ` Volodymyr Babchuk
2019-10-01 22:19   ` Stefano Stabellini
2019-10-01 22:44     ` Julien Grall
2019-10-01 22:52       ` Stefano Stabellini
2019-09-26 18:38 ` [Xen-devel] [PATCH RFC for-4.13 10/10] xen/arm64: entry: Ensure the guest state is synced when receiving a vSError Julien Grall
2019-09-27 15:30   ` Volodymyr Babchuk
2019-10-02  0:50   ` Stefano Stabellini
2019-09-27  4:17 ` [Xen-devel] [PATCH RFC for-4.13 00/10] xen/arm: XSA-201 and XSA-263 fixes Jürgen Groß

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=af8c7f32-699b-7611-495b-575a81361952@arm.com \
    --to=julien.grall@arm.com \
    --cc=Andre.Przywara@arm.com \
    --cc=Volodymyr_Babchuk@epam.com \
    --cc=andrii.anisov@gmail.com \
    --cc=nd@arm.com \
    --cc=sstabellini@kernel.org \
    --cc=xen-devel@lists.xenproject.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.