On Thu, 26 Jun 2025 12:39:41 +0100, Yicong Yang yangyicong@huawei.com wrote:
On 2025/6/26 16:51, Marc Zyngier wrote:
On Thu, 26 Jun 2025 09:09:02 +0100, Yicong Yang yangyicong@huawei.com wrote:
[...]
- /*
* 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* Hand it to the userspace.*/- if (esr_fsc_is_excl_atomic_fault(kvm_vcpu_get_esr(vcpu))) {
struct kvm_run *run = vcpu->run;run->exit_reason = KVM_EXIT_ARM_LDST64B;run->arm_nisv.esr_iss = kvm_vcpu_dabt_iss_nisv_sanitized(vcpu);run->arm_nisv.fault_ipa = fault_ipa |(kvm_vcpu_get_hfar(vcpu) & (vma_pagesize - 1));return -EAGAIN;- }
I'm not sure that's the right thing to do.
If:
the guest was told it doesn't have LS64WB,
it was told that some range is memory,
it uses that range as device,
thanks to FWB the resulting memory type is "Normal-Cacheable"
which results in an Unsupported Atomic exception
why would we involve the VMM at all? The VMM clearly said it didn't want to be involved in this (we have a memslot).
ok I thought we should make VMM do the decision in all the cases(both here and emulated MMIO) based on the last discussion[*], I may misunderstand it. If this is the case...
I think we should simply inject the corresponding S1 fault back into the guest.
let's simply inject a corresponding DABT back here and only make the VMM handle the emulated MMIO case. will update if no further comment.
A permission fault at S2 for a R/O memslot should definitely be relayed to userspace. But the question is whether the HW would report a permission fault or an unsupported atomic or exclusive fault (UAoEF for short).
If the HW supports LS64WB, I'd fully expect to get a permission fault, not an UAoEF, and we can perfectly report this to userspace with full decode information (though this doesn't fit in the KVM_EXIT_MMIO structure -- that's "only" an ABI problem).
If it doesn't, then we have a much bigger issue, and I don't think we can realistically triage the exception in a meaningful way -- we just can't know the reason why we failed, and we don't even know whether this was a load or store.
Overall, I can see two options here:
- we limit the LS64 support to HW that supports LS64WB (too bad for the other implementations, which is 100% of them). We can always triage the exception correctly, and we're unlikely to ever take an UAoEF in this context.
- we define that R/O memslots do not support LS64 accesses at all, which is always a valid implementation -- the architecture makes no provision of which pieces of addressable memory supports an access type or another. With that, we can always inject the UAoEF back into the guest without any further triaging.
Oliver, what do you think?
M.