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
[email protected]
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
