Re: [PATCH v1 0/3] manually add Error Synchronization Barrier at exception handler entry and exit
On 2017/11/1 19:32, James Morse wrote: >> RAS for firmware first support". In Huawei's platform, we do not >> support IESB, so software needs to insert that. > Surely you don't implement it because your CPU doesn't need it. Can > unrecoverable errors really cross an exception without becoming an SError? CC lishuo and liujun. Hi James, we will needs that if we can ensure that the Error is not propagated. The unrecoverable errors can cross an different exception, so hardware use IESB to isolate it. Afterwards we may also not support IESB(about the definition as shown in [3] ), the reason that we are not support IESB is that hardware colleague think software insert it in exception entry/exit can be flexibly. And ARM spec allow that: ARM spec allow software inset ESB instead of hardware insert as shown in [1]. About how to use the ESB in the software, the SPEC even give an example[2]: [1] AArch_v8A_v8.2_Extension_ARM-ECM-0326763-20-0: "ARMv8.2 adds an extension to RAS to allow system software to insert implicit Error Synchronization Barrier operations at exception handler entry and exit". [2] RAS_Extension_PRD03-PRDC-010953-39-0: Example exception entry sequence Example 1 shows a typical sequence for exception entry. Vector: ESB ;; Error Synchronization Barrier SUB SP,SP,#34*8 STP X0,X1,[SP] ;; Save all general purpose registers STP X2,X3,[SP,#2*8] ... STP X28,X29,[SP,#28*8] MRS X21,SP_EL0 MRS X22,ELR_EL1 ;; Save exception syndrome registers MRS X23,SPSR_EL1 STP X30,X21,[SP,#30*8] STP X22,X23,[SP,#32*8] ... MRS X21,DISR_EL1;; Check for deferred error TBNZ X21,#DISR_A_bit,Error_Handler MSR DAIFClr,#0xF;; Clear flags Example 1: Exception entry sequence [3] Below is the SCTLR_ELx.IESB definition. SCTLR_ELx[21]: IESB – Implicit Error Synchronization Barrier enable. 0: Disabled. 1: An implicit ErrorSynchronizationBarrier() call is added: After each exception taken to ELx. Before the operational pseudocode of each ERET instruction executed at ELx. Hi lishuo/liujun, could you explain more to James about the reason that why we need software inserts ESB instead of hardware support IESB? > > The ESB instruction does the barrier, but it also consumes any pending SError. > As it is this series will silently consume-and-discard uncontainable errors. In the firmware-first solution, if ESB consumed a SError, it will trap to firmware. firmware will handle it and record the Error. the DISR_EL1 will not record, so no need to Check for deferred error But if it is non-firmware solution, it will not trap, it needs to check the defered error through DISR_EL1 and call the Error_Handler, as shown in [2]. In the kernel patchset, I do not are check the defered error. If you think it should be added, I can add it. welcome comments. ___ kvmarm mailing list kvmarm@lists.cs.columbia.edu https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
Re: [PATCH v1 0/3] manually add Error Synchronization Barrier at exception handler entry and exit
Hi Dongjiu Geng, On 01/11/17 19:14, Dongjiu Geng wrote: > Some hardware platform can support RAS Extension, but not support IESB, > such as Huawei's platform, so software need to insert Synchronization Barrier > operations at exception handler entry. > > This series patches are based on James's series patches "SError rework + > RAS for firmware first support". In Huawei's platform, we do not > support IESB, so software needs to insert that. Surely you don't implement it because your CPU doesn't need it. Can unrecoverable errors really cross an exception without becoming an SError? The ESB instruction does the barrier, but it also consumes any pending SError. As it is this series will silently consume-and-discard uncontainable errors. Thanks, James ___ kvmarm mailing list kvmarm@lists.cs.columbia.edu https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
Re: [PATCH v1 0/3] manually add Error Synchronization Barrier at exception handler entry and exit
On 01/11/17 19:14, Dongjiu Geng wrote: > Some hardware platform can support RAS Extension, but not support IESB, > such as Huawei's platform, so software need to insert Synchronization Barrier > operations at exception handler entry. > > This series patches are based on James's series patches "SError rework + > RAS for firmware first support". In Huawei's platform, we do not > support IESB, so software needs to insert that. > > > Dongjiu Geng (3): > arm64: add a macro for SError synchronization > arm64: add error synchronization barrier in kernel_entry/kernel_exit > KVM: arm64: add ESB in exception handler entry and exit. > > James Morse (18): > arm64: explicitly mask all exceptions > arm64: introduce an order for exceptions > arm64: Move the async/fiq helpers to explicitly set process context > flags > arm64: Mask all exceptions during kernel_exit > arm64: entry.S: Remove disable_dbg > arm64: entry.S: convert el1_sync > arm64: entry.S convert el0_sync > arm64: entry.S: convert elX_irq > KVM: arm/arm64: mask/unmask daif around VHE guests > arm64: kernel: Survive corrected RAS errors notified by SError > arm64: cpufeature: Enable IESB on exception entry/return for > firmware-first > arm64: kernel: Prepare for a DISR user > KVM: arm64: Set an impdef ESR for Virtual-SError using VSESR_EL2. > KVM: arm64: Save/Restore guest DISR_EL1 > KVM: arm64: Save ESR_EL2 on guest SError > KVM: arm64: Handle RAS SErrors from EL1 on guest exit > KVM: arm64: Handle RAS SErrors from EL2 on guest exit > KVM: arm64: Take any host SError before entering the guest > > Xie XiuQi (2): > arm64: entry.S: move SError handling into a C function for future > expansion > arm64: cpufeature: Detect CPU RAS Extentions > > arch/arm64/Kconfig | 33 +- > arch/arm64/include/asm/assembler.h | 59 +--- > arch/arm64/include/asm/barrier.h | 1 + > arch/arm64/include/asm/cpucaps.h | 4 +- > arch/arm64/include/asm/daifflags.h | 61 + > arch/arm64/include/asm/esr.h | 17 +++ > arch/arm64/include/asm/exception.h | 14 ++ > arch/arm64/include/asm/irqflags.h| 40 ++-- > arch/arm64/include/asm/kvm_emulate.h | 10 > arch/arm64/include/asm/kvm_host.h| 16 +++ > arch/arm64/include/asm/processor.h | 2 + > arch/arm64/include/asm/sysreg.h | 6 +++ > arch/arm64/include/asm/traps.h | 36 +++ > arch/arm64/kernel/asm-offsets.c | 1 + > arch/arm64/kernel/cpufeature.c | 43 ++ > arch/arm64/kernel/debug-monitors.c | 5 +- > arch/arm64/kernel/entry.S| 88 > +--- > arch/arm64/kernel/hibernate.c| 5 +- > arch/arm64/kernel/machine_kexec.c| 4 +- > arch/arm64/kernel/process.c | 3 ++ > arch/arm64/kernel/setup.c| 8 ++-- > arch/arm64/kernel/signal.c | 8 +++- > arch/arm64/kernel/smp.c | 12 ++--- > arch/arm64/kernel/suspend.c | 7 +-- > arch/arm64/kernel/traps.c| 64 +- > arch/arm64/kvm/handle_exit.c | 19 +++- > arch/arm64/kvm/hyp-init.S| 3 ++ > arch/arm64/kvm/hyp/entry.S | 15 ++ > arch/arm64/kvm/hyp/hyp-entry.S | 1 + > arch/arm64/kvm/hyp/switch.c | 19 ++-- > arch/arm64/kvm/hyp/sysreg-sr.c | 6 +++ > arch/arm64/kvm/inject_fault.c| 13 +- > arch/arm64/kvm/sys_regs.c| 1 + > arch/arm64/mm/proc.S | 14 -- > virt/kvm/arm/arm.c | 4 ++ > 35 files changed, 527 insertions(+), 115 deletions(-) > create mode 100644 arch/arm64/include/asm/daifflags.h If you're sending a patch series, please have the cover letter describe *those patches*, rather than dozens of other patches that aren't part of it. This diffstat and summary is very confusing. Robin. ___ kvmarm mailing list kvmarm@lists.cs.columbia.edu https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
