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

[Wei Chen <Wei.Chen@xxxxxxx>]

Thanks to you and Julien :)

On 2017/4/6 3: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
>>
> 


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