Ok, thanks for James's confirmation. Another question, For the SEI, I want to also use SIGBUS both for the KVM user and non-kvm user, if SEA and SEI Error all use the SIGBUS to notify user space(Qemu), the user space(Qemu) will be confused, and do not know whether this is SEA or SEI error. so here I pass the sysreg ESR_EL2(vcpu->arch.fault.esr_el2) to the user space, let user space judges the (vcpu->arch.fault.esr_el2)'s value to know this is a SEA or SEI Error. do you agree my solution for the SEI? thanks. because the vcpu->arch.fault.esr_el2 can not directly passed to userspace, so I defined the vcpu->arch.fault.esr_el2 to sysreg ESR_EL2/FAR_EL2, sysreg register can pass to user space. + vcpu_sys_reg(vcpu,ESR_EL2) = kvm_vcpu_get_hsr(vcpu); + vcpu_sys_reg(vcpu,FAR_EL2) = kvm_vcpu_get_hfar(vcpu); On 2017/8/8 0:59, James Morse wrote: > Hi gengdongjiu, > > On 07/08/17 17:23, gengdongjiu wrote: >> As James's suggestion, I move injection SEA Error logic to the user space(Qemu), Qemu sets the related guest OS esr/elr/pstate/spsr > > (because for firmware-first its the CPER records that matter, and only QEMU > knows where it reserved the memory for these, and what it told the guest it > would use as the notification method). > >> through IOCTL KVM_SET_ONE_REG. For the SEA, when Qemu sets the esr_el1.IL bit, it needs to refer to esr_el2.IL, else Qemu does not know the trapped >> instruction was a 16-bit or a 32-bit instruction, also it needs to set far_el1 using far_el2, because this is synchronization abort. > > The 32bit kernel doesn't support ACPI firmware first, and aarch64 doesn't > support 16-bit instructions. thanks, so how about the SEA's error FAR_EL1's value? may be FAR_EL1's value get from FAR_EL2's value. > > > James > > > > . >
