| Message ID | 1503916701-13516-6-git-send-email-gengdongjiu@huawei.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
Hi Dongjiu Geng, On 28/08/17 11:38, Dongjiu Geng wrote: > ARMv8.2 adds a new bit HCR_EL2.TEA which controls to > route synchronous external aborts to EL2, and adds a > trap control bit HCR_EL2.TERR which controls to > trap all Non-secure EL1&0 error record accesses to EL2. > > This patch enables the two bits for the guest OS. > when an synchronous abort is generated in the guest OS, > it will trap to EL3 firmware, EL3 firmware will check the > HCR_EL2.TEA value to decide to jump to hypervisor or host > OS. (This is what you are using this for, the patch has nothing to do with EL3.) > Enabling HCR_EL2.TERR makes error record access > from guest trap to EL2. KVM already handles external aborts from lower exception levels, no more work needs doing for TEA. What happens when a guest access the RAS-Error-Record registers? Before we can set HCR_EL2.TERR I think we need to add some minimal emulation for the registers it traps. Most of them should be RAZ/WI, so it should be straightforward. (I think KVMs default is to emulate an undef for unknown traps). Eventually we will want to back this with a page of memory that lets Qemu/kvmtool configure what the guest can see. (i.e. the emulated machine's errors for kernel-first handling.) Thanks, James
On 2017/9/8 0:31, James Morse wrote: > Hi Dongjiu Geng, > > On 28/08/17 11:38, Dongjiu Geng wrote: >> ARMv8.2 adds a new bit HCR_EL2.TEA which controls to >> route synchronous external aborts to EL2, and adds a >> trap control bit HCR_EL2.TERR which controls to >> trap all Non-secure EL1&0 error record accesses to EL2. >> >> This patch enables the two bits for the guest OS. >> when an synchronous abort is generated in the guest OS, > >> it will trap to EL3 firmware, EL3 firmware will check the >> HCR_EL2.TEA value to decide to jump to hypervisor or host >> OS. > > (This is what you are using this for, the patch has nothing to do with EL3.) No, EL3 will check the HCR_EL2.TEA to decide to jump to hypervisor or host kernel. > > >> Enabling HCR_EL2.TERR makes error record access >> from guest trap to EL2. > > > KVM already handles external aborts from lower exception levels, no more work > needs doing for TEA. when SCR_EL3.EA is set, TEA will not workable, El3 only check its value to decide to hypervisor or EL1 host kernel. > > What happens when a guest access the RAS-Error-Record registers? it will trap to EL2 kvm > > Before we can set HCR_EL2.TERR I think we need to add some minimal emulation for > the registers it traps. Most of them should be RAZ/WI, so it should be > straightforward. (I think KVMs default is to emulate an undef for unknown traps). if KVM default handling is to emulate an undef for unknown traps, how about we use its default way? because no one access the ERR RAS register in the guest . > > Eventually we will want to back this with a page of memory that lets > Qemu/kvmtool configure what the guest can see. (i.e. the emulated machine's > errors for kernel-first handling.) I think emulate it to an undef for unknown traps can be enough, no one access the ERR register in the guest. > > > Thanks, > > James > > . >
James, On 2017/9/8 0:31, James Morse wrote: > KVM already handles external aborts from lower exception levels, no more work > needs doing for TEA. If it is firmware first solution, that is SCR_EL3.EA=1, all SError interrupt and synchronous External Abort exceptions are taken to EL3, so EL3 firmware will handle it, KVM no needs to handle it. HCR_EL3.TEA is only for EL3 to check its value to decide to jump to hypervisor or kernel. > > What happens when a guest access the RAS-Error-Record registers? > > Before we can set HCR_EL2.TERR I think we need to add some minimal emulation for > the registers it traps. Most of them should be RAZ/WI, so it should be > straightforward. (I think KVMs default is to emulate an undef for unknown traps). Today I added the support to do some minimal emulation for RAS-Error-Record registers, thanks for the good suggestion. > > Eventually we will want to back this with a page of memory that lets > Qemu/kvmtool configure what the guest can see. (i.e. the emulated machine's > errors for kernel-first handling.)
Hi gengdongjiu, On 14/09/17 12:12, gengdongjiu wrote: > On 2017/9/8 0:31, James Morse wrote: >> KVM already handles external aborts from lower exception levels, no more work >> needs doing for TEA. > If it is firmware first solution, that is SCR_EL3.EA=1, all SError interrupt and synchronous External > Abort exceptions are taken to EL3, so EL3 firmware will handle it, KVM no needs to handle it. ... and presumably your firmware generates a fake-Synchronous-external-abort to hand to EL2 as an APEI SEA notification? My point: this is fine, KVM already handles synchronous-external aborts, no more work needed for this trap, (in contrast to the TERR, which you've fixed) > HCR_EL3.TEA is only for EL3 to check its value to decide to jump to hypervisor or kernel. HCR_EL3!?! >> What happens when a guest access the RAS-Error-Record registers? >> >> Before we can set HCR_EL2.TERR I think we need to add some minimal emulation for >> the registers it traps. Most of them should be RAZ/WI, so it should be >> straightforward. (I think KVMs default is to emulate an undef for unknown traps). > Today I added the support to do some minimal emulation for RAS-Error-Record registers, thanks > for the good suggestion. Thanks. Software has the bad habit of living much longer than we think, if KVM traps part of the architecture then we have to emulate it... Some bright spark might boot a future Linux-v4.42 guest on a Linux-v4.16 host. I had a run through the RAS spec: if we make ERRIDR_EL1 RAZ/WI then we can do the same with ERRSELR_EL1. Then following the rules for 'If ERRSELR_EL1.SEL is [>=] ERRIDR_EL1.NUM' that makes the ERX* registers RAZ/WI too. >> Eventually we will want to back this with a page of memory that lets >> Qemu/kvmtool configure what the guest can see. (i.e. the emulated machine's >> errors for kernel-first handling.) Thanks, James
Hi gengdongjiu, On 14/09/17 12:12, gengdongjiu wrote: > On 2017/9/8 0:31, James Morse wrote: >> KVM already handles external aborts from lower exception levels, no more work >> needs doing for TEA. > If it is firmware first solution, that is SCR_EL3.EA=1, all SError interrupt and synchronous External > Abort exceptions are taken to EL3, so EL3 firmware will handle it, KVM no needs to handle it. > > HCR_EL3.TEA is only for EL3 to check its value to decide to jump to hypervisor or kernel. > >> >> What happens when a guest access the RAS-Error-Record registers? >> >> Before we can set HCR_EL2.TERR I think we need to add some minimal emulation for >> the registers it traps. Most of them should be RAZ/WI, so it should be >> straightforward. (I think KVMs default is to emulate an undef for unknown traps). > Today I added the support to do some minimal emulation for RAS-Error-Record registers, thanks > for the good suggestion. Where can I find this patch? I'd like to repost it as part of the SError_rework/RAS/IESB series: this is one of the bits KVM needs but I didn't touch as it looks like your updated version of this patch should cover it. Thanks, James
Hi James, > >> Today I added the support to do some minimal emulation for >> RAS-Error-Record registers, thanks >> for the good suggestion. > > Where can I find this patch? > I'd like to repost it as part of the SError_rework/RAS/IESB series: this is > one > of the bits KVM needs but I didn't touch as it looks like your updated > version > of this patch should cover it. I have updated this patch according your suggestion that do some emulation for the ERR* trap. and have verified it. but still not sent it out. Tomorrow I will send it out for your review(now it is Chinese midnight), if you think it is ok, you can add it as part of the SError_rework/RAS/IESB series. thanks for your reminder and good review comments. > > > Thanks, > > James > _______________________________________________ > kvmarm mailing list > kvmarm@lists.cs.columbia.edu > https://lists.cs.columbia.edu/mailman/listinfo/kvmarm >
diff --git a/arch/arm64/include/asm/kvm_arm.h b/arch/arm64/include/asm/kvm_arm.h index 61d694c2eae5..1188272003c4 100644 --- a/arch/arm64/include/asm/kvm_arm.h +++ b/arch/arm64/include/asm/kvm_arm.h @@ -23,6 +23,8 @@ #include <asm/types.h> /* Hyp Configuration Register (HCR) bits */ +#define HCR_TEA (UL(1) << 37) +#define HCR_TERR (UL(1) << 36) #define HCR_E2H (UL(1) << 34) #define HCR_ID (UL(1) << 33) #define HCR_CD (UL(1) << 32) diff --git a/arch/arm64/include/asm/kvm_emulate.h b/arch/arm64/include/asm/kvm_emulate.h index fe39e6841326..47983db27de2 100644 --- a/arch/arm64/include/asm/kvm_emulate.h +++ b/arch/arm64/include/asm/kvm_emulate.h @@ -47,6 +47,13 @@ static inline void vcpu_reset_hcr(struct kvm_vcpu *vcpu) vcpu->arch.hcr_el2 = HCR_GUEST_FLAGS; if (is_kernel_in_hyp_mode()) vcpu->arch.hcr_el2 |= HCR_E2H; + if (cpus_have_const_cap(ARM64_HAS_RAS_EXTN)) { + /* route synchronous external abort exceptions to EL2 */ + vcpu->arch.hcr_el2 |= HCR_TEA; + /* trap error record accesses */ + vcpu->arch.hcr_el2 |= HCR_TERR; + } + if (test_bit(KVM_ARM_VCPU_EL1_32BIT, vcpu->arch.features)) vcpu->arch.hcr_el2 &= ~HCR_RW; }
ARMv8.2 adds a new bit HCR_EL2.TEA which controls to route synchronous external aborts to EL2, and adds a trap control bit HCR_EL2.TERR which controls to trap all Non-secure EL1&0 error record accesses to EL2. This patch enables the two bits for the guest OS. when an synchronous abort is generated in the guest OS, it will trap to EL3 firmware, EL3 firmware will check the HCR_EL2.TEA value to decide to jump to hypervisor or host OS. Enabling HCR_EL2.TERR makes error record access from guest trap to EL2. change since v5: 1. modify some patch description Signed-off-by: Dongjiu Geng <gengdongjiu@huawei.com> --- arch/arm64/include/asm/kvm_arm.h | 2 ++ arch/arm64/include/asm/kvm_emulate.h | 7 +++++++ 2 files changed, 9 insertions(+)