Hi Yicong,
On Mon, Mar 31, 2025 at 05:43:20PM +0800, Yicong Yang wrote:
From: Yicong Yang yangyicong@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