Hi James.
You are right. For the SEI case, the ESR_EL1 may not need to refer to ESR_EL2's value.
But for the SEA case, the ESR_EL1 may need to refer to ESR_EL2's value.
For example, the 16bit/32bit instruction-length, it may needs to check the ESR_EL2's bit 25.
Because when happen SEA, it jump to SEA vector table entry by software( after setting the elr_el2 and esr_el2, and use eret instruction to jump to the SEA vector table ), not by hardware(such as virtual SEI)
>
> Hi gengdongjiu,
>
> On 24/07/17 16:24, gengdongjiu wrote:
> > From above description, in the firmware-first RAS solution, UEFI copy
> > the
> > ESR_EL3 to the ESR_EL2,
>
> UEFI at EL3? Do you mean ATF? or some component of UEFI that got loaded into secure-world to do the CPER record generation?
UEFI is firmware. Which is at EL3. Yes, it is ATF.
>
>
> > do you agree EL2 refer to the ESR_EL2 value to set the ESR_EL1 value
> > when inject the abort?
>
> Refer-to: yes. It needs to honour any bits that are part of the guest state that may be represented in the ESR.
>
> This is what your KVM example is doing, but this is a pretty arcane path: If on the 32bit kernel, we read/write or execute from an address
> whose stage 1 page-table-walk walks through a stage 2 mapping that is marked as device memory, then we report this as an
> instruction/data abort to the guest, instead of resolving the stage2 mapping.
Yes, only report the instruction/data abort to the guest can be enough.
>
> In this case we preserve the 16bit/32bit instruction-length value reported in the ESR as its part of the guest state that would have been
> reported if the
> stage1 fault were delivered directly.
For the SEI case, the 16bit/32bit instruction-length does not need to passed.
But for the SEA, the 16bit/32bit instruction-length value may be need to pass, as you see below. It check(if (kvm_vcpu_trap_il_is32bit(vcpu)) ) and pass the ESR_ELx_IL
static void inject_abt64(struct kvm_vcpu *vcpu, bool is_iabt, unsigned long addr)
{
unsigned long cpsr = *vcpu_cpsr(vcpu);
bool is_aarch32 = vcpu_mode_is_32bit(vcpu);
u32 esr = 0;
*vcpu_elr_el1(vcpu) = *vcpu_pc(vcpu);
*vcpu_pc(vcpu) = get_except_vector(vcpu, except_type_sync);
*vcpu_cpsr(vcpu) = PSTATE_FAULT_BITS_64;
*vcpu_spsr(vcpu) = cpsr;
vcpu_sys_reg(vcpu, FAR_EL1) = addr;
/*
* Build an {i,d}abort, depending on the level and the
* instruction set. Report an external synchronous abort.
*/
if (kvm_vcpu_trap_il_is32bit(vcpu))
esr |= ESR_ELx_IL;
.......................................................................
}
>
>
> Is it valid to pass values from a host SError into a guest?
Do you mean pass the ESR value from host to guest?
And do you mean we should not pass ESR value when inject the SEI?
> For RAS on Linux+KVM, I don't think this is the right thing to do. If we receive a RAS event, the host must completely process the error and
> notify any in-kernel users and userspace.
I agree, so deliver signal to user space such as QEMU is through memory failure for SEI? May be this can also suitable to no-KVM case.
> KVM shouldn't assume an SError is a firmware-first notification and that it should pass the same notification into the guest.
"it should pass the same notification into the guest"-------what is the mean of the notification?
>
> We need to think of SError (which may be the un-synchronizable kind from a device), separately from SEI as a APEI notification. Even for
> device pass-through firmware-first errors may be reported by another notification method. We shouldn't duplicate or break the
> functionality because the error wasn't reported by SEI.
>
> I agree device pass-through is a special case where KVM is more like an in-kernel user of the device. In this case I think we need the host's
> device driver, (there must be one, to at least reset the device) to check that this RAS event hasn't broken the device's isolation. Is it still
> safe for the guest to access?
> e.g. With PCIe a Virtual-Function using SR-IOV may have had its BARs corrupted.
> Allowing a guest to touch this device could compromise another guest, or the host.
>
> The SError ESR contains implementation-defined bits. I'm against giving these bits to user-space as we don't know what they mean. KVM
> wants to provide an abstract machine, which we can migrated between hosts running on different vendors platforms. With v8.2 SErrors are
> either the vanilla device kind, these only have an implementation-defined ESR, we shouldn't give this to user space, or RAS errors, we
> shouldn't give these to user space either as code using this value won't work if the APEI notification method isn't SEI.
SEA ESR：0x92000410
SEI ESR： 0xbf000006
As shown above, For example, when happen SEA, the ESR value is 0x92000410; when happen SEI, the ESR value is 0xbf000006.
So for above two cases, I want to consult with you what is the ESR value do you suggested to passed to the guest OS for above SEA and SEI ?
>
>
> The version of the RAS spec you refer to here is for partners implementing CPUs, it describes what software might do, so that the CPU
> works well for different current (and future) operating systems. It isn't a guide to what all software should do.
>
> >> Variant: asynchronous External Abort with delegated exception
> >> handling The example above requires the hypervisor to know that it can delegate the error exception to the OS using a virtual error
> interrupt.
>
> We don't have delegated exception handling. The host may-or-may-not have an SEA/SEI GHES notification, the guest may-or-may-not have a
> SEA/SEI GHES notification.
>
>
>
> Thanks,
>
> James
> IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the
> intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or
> store or copy the information in any medium. Thank you.
_______________________________________________
kvmarm mailing list
kvmarm@xxxxxxxxxxxxxxxxxxxxx
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
