[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



Hi,

I just noticed that commit b32d442abd "setup vwfi correctly on cpu0" has not been revered as asked by Stefano (see [1]).

Stefano, can you revert it?

Cheers,

[1] https://lists.xenproject.org/archives/html/xen-devel/2017-04/msg00264.html

On 05/04/17 20:18, Stefano Stabellini wrote:
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


--
Julien Grall

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

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.