Re: [Xen-devel] [PATCH v4 00/19] Provide a command line option to choose how to handle SErrors

[Stefano Stabellini <sstabellini@xxxxxxxxxx>]

Thank you Wei. I committed this series. I fixed on commit patch #16 that
has 2 asserts.

On Wed, 5 Apr 2017, Wei Chen wrote:
> From XSA-201, we know that, a guest could trigger SErrors when accessing
> memory mapped HW in a non-conventional way. In the patches for XSA-201,
> we crash the guest when we captured such asynchronous aborts to avoid data
> corruption.
> 
> In order to distinguish guest-generated SErrors from hypervisor-generated
> SErrors. We have to place SError checking code in every EL1 -> EL2 paths.
> That will be an overhead on entries caused by dsb/isb.
> 
> But not all platforms want to categorize the SErrors. For example, a host
> that is running with trusted guests. The administrator can confirm that
> all guests that are running on the host will not trigger such SErrors. In
> this user scene, we should provide some options to administrator to avoid
> categorizing the SErrors. And then reduce the overhead of dsb/isb.
> 
> We provided following 3 options to administrator to determine how to handle
> the SErrors:
> 
> * `diverse`:
>   The hypervisor will distinguish guest SErrors from hypervisor SErrors.
>   The guest generated SErrors will be forwarded to guests, the hypervisor
>   generated SErrors will cause the whole system crash.
>   It requires:
>   1. Place dsb/isb on all EL1 -> EL2 trap entries to categorize SErrors
>      correctly.
>   2. Place dsb/isb on EL2 -> EL1 return paths to prevent slipping hypervisor
>      SErrors to guests.
>   3. Place dsb/isb in context switch to isolate the SErrors between 2 vCPUs.
> 
> * `forward`:
>   The hypervisor will not distinguish guest SErrors from hypervisor SErrors.
>   All SErrors will be forwarded to guests, except the SErrors generated when
>   idle vCPU is running. The idle domain doesn't have the ability to hanle the
>   SErrors, so we have to crash the whole system when we get SErros with idle
>   vCPU. This option will avoid most overhead of the dsb/isb, except the 
> dsb/isb
>   in context switch which is used to isolate the SErrors between 2 vCPUs.
> 
> * `panic`:
>   The hypervisor will not distinguish guest SErrors from hypervisor SErrors.
>   All SErrors will crash the whole system. This option will avoid all overhead
>   of the dsb/isb
> 
> ---
> v3->v4:
> 1. Rename SKIP_CHECK_PENDING_VSERROR to SKIP_SYNCHRONIZE_SERROR_ENTRY_EXIT.
> 2. Add ASSERT in SYNCHRONIZING_SERROR macro to ensure abort is enabled.
> 3. Use one local_abort_is_enabled for ARM32 and ARM64.
> 4. Fix some grammer issues.
> 5. Add Reviewed-by tags from Julien and Stefano for most of this series.
> 
> Wei Chen (19):
>   xen/arm: Save ESR_EL2 to avoid using mismatched value in syndrome
>     check
>   xen/arm: Introduce a helper to get default HCR_EL2 flags
>   xen/arm: Set and restore HCR_EL2 register for each vCPU separately
>   xen/arm: Avoid setting/clearing HCR_RW at every context switch
>   xen/arm: Save HCR_EL2 when a guest took the SError
>   xen/arm: Introduce a virtual abort injection helper
>   xen/arm: Introduce a command line parameter for SErrors/Aborts
>   xen/arm: Introduce a initcall to update cpu_hwcaps by serror_op
>   xen/arm64: Use alternative to skip the check of pending serrors
>   xen/arm32: Use alternative to skip the check of pending serrors
>   xen/arm: Move macro VABORT_GEN_BY_GUEST to common header
>   xen/arm: Introduce new helpers to handle guest/hyp SErrors
>   xen/arm: Replace do_trap_guest_serror with new helpers
>   xen/arm: Unmask the Abort/SError bit in the exception entries
>   xen/arm: Introduce a helper to check local abort is enabled
>   xen/arm: Introduce a macro to synchronize SError
>   xen/arm: Isolate the SError between the context switch of 2 vCPUs
>   xen/arm: Prevent slipping hypervisor SError to guest
>   xen/arm: Handle guest external abort as guest SError
> 
>  docs/misc/xen-command-line.markdown   |  44 ++++++++
>  xen/arch/arm/arm32/asm-offsets.c      |   1 +
>  xen/arch/arm/arm32/entry.S            |  28 ++++-
>  xen/arch/arm/arm32/traps.c            |   5 +-
>  xen/arch/arm/arm64/asm-offsets.c      |   1 +
>  xen/arch/arm/arm64/domctl.c           |   6 ++
>  xen/arch/arm/arm64/entry.S            | 105 +++++++++----------
>  xen/arch/arm/arm64/traps.c            |   2 +-
>  xen/arch/arm/domain.c                 |  19 ++++
>  xen/arch/arm/domain_build.c           |   7 ++
>  xen/arch/arm/p2m.c                    |  10 +-
>  xen/arch/arm/traps.c                  | 187 
> +++++++++++++++++++++++++++++-----
>  xen/include/asm-arm/arm32/processor.h |  12 +--
>  xen/include/asm-arm/arm64/processor.h |   3 +-
>  xen/include/asm-arm/cpufeature.h      |   4 +-
>  xen/include/asm-arm/domain.h          |   4 +
>  xen/include/asm-arm/processor.h       |  30 +++++-
>  xen/include/asm-arm/system.h          |   7 ++
>  18 files changed, 364 insertions(+), 111 deletions(-)
> 
> -- 
> 2.7.4
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@xxxxxxxxxxxxx
> https://lists.xen.org/xen-devel
> 

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