All of lore.kernel.org
 help / color / mirror / Atom feed
From: Stefano Stabellini <sstabellini@kernel.org>
To: Wei Chen <Wei.Chen@arm.com>
Cc: sstabellini@kernel.org, steve.capper@arm.com,
	xen-devel@lists.xen.org, Kaly.Xin@arm.com, julien.grall@arm.com,
	nd@arm.com
Subject: Re: [PATCH v3 16/19] xen/arm: Introduce a macro to synchronize SError
Date: Fri, 31 Mar 2017 11:36:37 -0700 (PDT)	[thread overview]
Message-ID: <alpine.DEB.2.10.1703311136210.2723@sstabellini-ThinkPad-X260> (raw)
In-Reply-To: <1490965679-619-17-git-send-email-Wei.Chen@arm.com>

On Fri, 31 Mar 2017, Wei Chen wrote:
> In previous patches, we have provided the ability to synchronize
> SErrors in exception entries. But we haven't synchronized SErrors
> while returning to guest and doing context switch.
> 
> So we still have two risks:
> 1. Slipping hypervisor SErrors to guest. For example, hypervisor
>    triggers a SError while returning to guest, but this SError may be
>    delivered after entering guest. In "DIVERSE" option, this SError
>    would be routed back to guest and panic the guest. But actually,
>    we should crash the whole system due to this hypervisor SError.
> 2. Slipping previous guest SErrors to the next guest. In "FORWARD"
>    option, if hypervisor triggers a SError while context switching.
>    This SError may be delivered after switching to next vCPU. In this
>    case, this SError will be forwarded to next vCPU and may panic
>    an incorrect guest.
> 
> So we have have to introduce this macro to synchronize SErrors while
> returning to guest and doing context switch.
> 
> We also added a barrier to this macro to prevent compiler reorder our
> asm volatile code.
> 
> Signed-off-by: Wei Chen <Wei.Chen@arm.com>

Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>


> ---
> v2->v3:
> 1. Use a macro to replace function to synchronize SErrors.
> 2. Add barrier to avoid compiler reorder our code.
> 
> Note:
> I had followed Julien's suggestion to add the Assert in to macro,
> But I found I always hit the Assert. Because when option == DIVERSE,
> the SKIP_CHECK_PENDING_VSERROR feature would not be set into cpu_hwcaps.
> And in the later patch, I will use this feature to skip synchronize
> SErrors before returning to guest.
> The cpus_has_cap(SKIP_CHECK_PENDING_VSERROR) will always false.
> And hit the ASSERT.
> 
> And about the local_abort enable check, should we disable the abort
> before synchronizing SErrors while returning to guest or doing context
> switch? Just like in these two places we have disable the IRQ.
> 
> For this testing, I have apply this series to latest staging tree.
> 
> ...
> (XEN) Command line: console=dtuart dtuart=serial0 conswitch=x loglvl=all
> dom0_mem=8G dom0_max_vcpus=8 serrors=diverse
> (XEN) Placing Xen at 0x00000083fee00000-0x00000083ff000000
> ...
> (XEN) ----SYNCHRONIZE_SERROR ASSERT 0 1
> (XEN) Assertion 'cpus_have_cap(5) && local_abort_is_enabled()' failed at
> traps.c:2954
> (XEN) ----[ Xen-4.9-unstable  arm64  debug=y   Not tainted ]----
> (XEN) CPU:    0
> (XEN) PC:     000000000025c09c leave_hypervisor_tail+0xa8/0x100
> (XEN) LR:     000000000025c078
> (XEN) SP:     00008003fac07e80
> (XEN) CPSR:   800002c9 MODE:64-bit EL2h (Hypervisor, handler)
> (XEN)      X0: 000000000000005a  X1: 00000000ffffffff  X2:
> 0000000000000000
> (XEN)      X3: 0000000000000000  X4: 0000000000000010  X5:
> 0000000000000000
> (XEN)      X6: 00008003ffe50000  X7: 0000000000000001  X8:
> 00000000fffffffd
> (XEN)      X9: 000000000000000a X10: 0000000000000031 X11:
> 00008003fac07bf8
> (XEN)     X12: 0000000000000001 X13: 000000000026c370 X14:
> 0000000000000020
> (XEN)     X15: 0000000000000000 X16: 00000083fff42fc0 X17:
> 00000000fffffffe
> (XEN)     X18: 0000000000000000 X19: 0000000000292c58 X20:
> 0000000000290028
> (XEN)     X21: 00000000002ea000 X22: 0000000000000000 X23:
> 0000000000000000
> (XEN)     X24: 0000000000000000 X25: 0000000000000000 X26:
> 0000000000000000
> (XEN)     X27: 0000000000000000 X28: 0000000000000000  FP:
> 00008003fac07e80
> (XEN)
> (XEN)   VTCR_EL2: 80043594
> (XEN)  VTTBR_EL2: 00010083fd036000
> (XEN)
> (XEN)  SCTLR_EL2: 30cd183d
> (XEN)    HCR_EL2: 000000008038663f
> (XEN)  TTBR0_EL2: 00000083fef0e000
> (XEN)
> (XEN)    ESR_EL2: f2000001
> (XEN)  HPFAR_EL2: 0000000000000000
> (XEN)    FAR_EL2: 0000000000000000
> (XEN)
> (XEN) Xen stack trace from sp=00008003fac07e80:
> (XEN)    00008003fac07ea0 0000000000262934 0000000000000000
> 0000000000000000
> (XEN)    0000000000000000 0000000000249cac 0000008048000000
> 0000000000000000
> (XEN)    0000000000000000 0000000000000000 0000000000000000
> 0000000000000000
> (XEN)    0000000000000000 0000000000000000 0000000000000000
> 0000000000000000
> (XEN)    0000000000000000 0000000000000000 0000000000000000
> 0000000000000000
> (XEN)    0000000000000000 0000000000000000 0000000000000000
> 0000000000000000
> (XEN)    0000000000000000 0000000000000000 0000000000000000
> 0000000000000000
> (XEN)    0000000000000000 0000000000000000 0000000000000000
> 0000000000000000
> (XEN)    0000000000000000 0000000000000000 0000000000000000
> 0000000000000000
> (XEN)    0000000000000000 0000000000000000 0000008040080000
> 00000000000001c5
> (XEN)    0000000000000000 0000000000000000 0000000000000000
> 0000000000000000
> (XEN)    0000000000000000 0000000000000000 0000000000000000
> 0000000000000000
> (XEN) Xen call trace:
> (XEN)    [<000000000025c09c>] leave_hypervisor_tail+0xa8/0x100 (PC)
> (XEN)    [<000000000025c078>] leave_hypervisor_tail+0x84/0x100 (LR)
> (XEN)    [<0000000000262934>] return_to_new_vcpu64+0x4/0x30
> (XEN)    [<0000000000249cac>] domain.c#continue_new_vcpu+0/0xa4
> (XEN)
> (XEN)
> (XEN) ****************************************
> (XEN) Panic on CPU 0:
> (XEN) Assertion 'cpus_have_cap(5) && local_abort_is_enabled()' failed at
> traps.c:2954
> (XEN) ****************************************
> (XEN)
> (XEN) Reboot in five seconds...
> ---
>  xen/include/asm-arm/processor.h | 11 +++++++++++
>  1 file changed, 11 insertions(+)
> 
> diff --git a/xen/include/asm-arm/processor.h b/xen/include/asm-arm/processor.h
> index bb24bee..a787d1b 100644
> --- a/xen/include/asm-arm/processor.h
> +++ b/xen/include/asm-arm/processor.h
> @@ -723,6 +723,17 @@ void abort_guest_exit_end(void);
>      ( (unsigned long)abort_guest_exit_end == (r)->pc ) \
>  )
>  
> +/*
> + * Synchronize SError unless the feature is selected.
> + * This is relying on the SErrors are currently unmasked.
> + */
> +#define SYNCHRONIZE_SERROR(feat)                                 \
> +    do {                                                         \
> +        asm volatile(ALTERNATIVE("dsb sy; isb",                  \
> +                                 "nop; nop", feat)               \
> +                                 : : : "memory");                \
> +    } while (0)
> +
>  #endif /* __ASSEMBLY__ */
>  #endif /* __ASM_ARM_PROCESSOR_H */
>  /*
> -- 
> 2.7.4
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

  parent reply	other threads:[~2017-03-31 18:36 UTC|newest]

Thread overview: 46+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-03-31 13:07 [PATCH v3 00/19] Provide a command line option to choose how to handle SErrors Wei Chen
2017-03-31 13:07 ` [PATCH v3 01/19] xen/arm: Save ESR_EL2 to avoid using mismatched value in syndrome check Wei Chen
2017-03-31 14:08   ` Julien Grall
2017-03-31 18:26   ` Stefano Stabellini
2017-03-31 13:07 ` [PATCH v3 02/19] xen/arm: Introduce a helper to get default HCR_EL2 flags Wei Chen
2017-03-31 14:10   ` Julien Grall
2017-03-31 18:29   ` Stefano Stabellini
2017-03-31 13:07 ` [PATCH v3 03/19] xen/arm: Set and restore HCR_EL2 register for each vCPU separately Wei Chen
2017-03-31 14:11   ` Julien Grall
2017-03-31 18:28   ` Stefano Stabellini
2017-03-31 13:07 ` [PATCH v3 04/19] xen/arm: Avoid setting/clearing HCR_RW at every context switch Wei Chen
2017-03-31 13:07 ` [PATCH v3 05/19] xen/arm: Save HCR_EL2 when a guest took the SError Wei Chen
2017-03-31 13:07 ` [PATCH v3 06/19] xen/arm: Introduce a virtual abort injection helper Wei Chen
2017-03-31 14:13   ` Julien Grall
2017-03-31 13:07 ` [PATCH v3 07/19] xen/arm: Introduce a command line parameter for SErrors/Aborts Wei Chen
2017-03-31 13:07 ` [PATCH v3 08/19] xen/arm: Introduce a initcall to update cpu_hwcaps by serror_op Wei Chen
2017-03-31 14:48   ` Julien Grall
2017-04-05  6:36     ` Wei Chen
2017-03-31 13:07 ` [PATCH v3 09/19] xen/arm64: Use alternative to skip the check of pending serrors Wei Chen
2017-03-31 13:07 ` [PATCH v3 10/19] xen/arm32: " Wei Chen
2017-03-31 13:07 ` [PATCH v3 11/19] xen/arm: Move macro VABORT_GEN_BY_GUEST to common header Wei Chen
2017-03-31 13:07 ` [PATCH v3 12/19] xen/arm: Introduce new helpers to handle guest/hyp SErrors Wei Chen
2017-03-31 13:07 ` [PATCH v3 13/19] xen/arm: Replace do_trap_guest_serror with new helpers Wei Chen
2017-03-31 13:07 ` [PATCH v3 14/19] xen/arm: Unmask the Abort/SError bit in the exception entries Wei Chen
2017-03-31 13:07 ` [PATCH v3 15/19] xen/arm: Introduce a helper to check local abort is enabled Wei Chen
2017-03-31 14:25   ` Julien Grall
2017-03-31 18:43   ` Stefano Stabellini
2017-03-31 13:07 ` [PATCH v3 16/19] xen/arm: Introduce a macro to synchronize SError Wei Chen
2017-03-31 14:33   ` Julien Grall
2017-04-05  7:14     ` Wei Chen
2017-04-05  7:29       ` Julien Grall
2017-04-05  7:35         ` Wei Chen
2017-04-05  8:02           ` Julien Grall
2017-04-05  8:08         ` Wei Chen
2017-04-05  8:20           ` Julien Grall
2017-04-05  8:32             ` Wei Chen
2017-03-31 18:36   ` Stefano Stabellini [this message]
2017-03-31 13:07 ` [PATCH v3 17/19] xen/arm: Isolate the SError between the context switch of 2 vCPUs Wei Chen
2017-03-31 14:38   ` Julien Grall
2017-03-31 18:37     ` Stefano Stabellini
2017-03-31 13:07 ` [PATCH v3 18/19] xen/arm: Prevent slipping hypervisor SError to guest Wei Chen
2017-03-31 14:46   ` Julien Grall
2017-03-31 18:42     ` Stefano Stabellini
2017-03-31 18:43       ` Julien Grall
2017-04-05  7:15         ` Wei Chen
2017-03-31 13:07 ` [PATCH v3 19/19] xen/arm: Handle guest external abort as guest SError Wei Chen

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=alpine.DEB.2.10.1703311136210.2723@sstabellini-ThinkPad-X260 \
    --to=sstabellini@kernel.org \
    --cc=Kaly.Xin@arm.com \
    --cc=Wei.Chen@arm.com \
    --cc=julien.grall@arm.com \
    --cc=nd@arm.com \
    --cc=steve.capper@arm.com \
    --cc=xen-devel@lists.xen.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.