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

Reply via email to