Hi Yicong,
On Mon, Mar 31, 2025 at 05:43:20PM +0800, Yicong Yang wrote:
> From: Yicong Yang <yangyic...@hisilicon.com>
>
> If FEAT_LS64WB not supported, FEAT_LS64* instructions only support
> to access Device/Uncacheable memory, otherwise a data abort for
> unsupported Exclusive or atomic access (0x35) is generated per spec.
> It's implementation defined whether the target exception level is
> routed and is possible to implemented as route to EL2 on a VHE VM.
> Per DDI0487K.a Section C3.2.12.2 Single-copy atomic 64-byte load/store:
>
> The check is performed against the resulting memory type after all
> enabled stages of translation. In this case the fault is reported
> at the final enabled stage of translation.
Just use section citations, this quote isn't very useful since it
doesn't adequately describe the different IMPLEMENTATION DEFINED
behavior.
> If it's implemented as generate the DABT to the final enabled stage
> (stage-2), inject a DABT to the guest to handle it.
This should be ordered _before_ the patch that exposes FEAT_LS64* to the
VM.
> @@ -1658,6 +1658,25 @@ static int user_mem_abort(struct kvm_vcpu *vcpu,
> phys_addr_t fault_ipa,
> if (exec_fault && device)
> return -ENOEXEC;
>
> + if (esr_fsc_is_excl_atomic_fault(kvm_vcpu_get_esr(vcpu))) {
> + /*
> + * Target address is normal memory on the Host. We come here
> + * because:
> + * 1) Guest map it as device memory and perform LS64 operations
> + * 2) VMM report it as device memory mistakenly
> + * Warn the VMM and inject the DABT back to the guest.
> + */
> + if (!device)
> + kvm_err("memory attributes maybe incorrect for hva
> 0x%lx\n", hva);
No, kvm_err() doesn't warn the VMM at all. KVM should never log anything
for a situation that can be caused by the guest, e.g. option #1 in your
comment.
Keep in mind that data aborts with DFSC == 0x35 can happen for a lot
more than LS64 instructions, e.g. an atomic on a Device-* mapping.
> @@ -1919,6 +1939,21 @@ int kvm_handle_guest_abort(struct kvm_vcpu *vcpu)
> goto out_unlock;
> }
>
> + /*
> + * If instructions of FEAT_{LS64, LS64_V} operated on
> + * unsupported memory regions, a DABT for unsupported
> + * Exclusive or atomic access is generated. It's
> + * implementation defined whether the exception will
> + * be taken to, a stage-1 DABT or the final enabled
> + * stage of translation (stage-2 in this case as we
> + * hit here). Inject a DABT to the guest to handle it
> + * if it's implemented as a stage-2 DABT.
> + */
> + if (esr_fsc_is_excl_atomic_fault(esr)) {
> + kvm_inject_dabt_excl_atomic(vcpu,
> kvm_vcpu_get_hfar(vcpu));
> + return 1;
> + }
> +
A precondition of taking such a data abort is having a valid mapping at
stage-2. If KVM can't resolve the HVA of the fault then there couldn't
have been a stage-2 mapping.
Thanks,
Oliver
