Re: [PATCH v3 3/7] KVM: arm64: Handle DABT caused by LS64* instructions on unsupported memory

[Marc Zyngier <maz@kernel.org>]

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.

-- 
Without deviation from the norm, progress is not possible.