[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
|
