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

[Yicong Yang]

On 2025/6/27 21:12, Marc Zyngier wrote:
> On Thu, 26 Jun 2025 12:39:41 +0100,
> Yicong Yang <yangyicong at huawei.com> wrote:
>>
>> On 2025/6/26 16:51, Marc Zyngier wrote:
>>> On Thu, 26 Jun 2025 09:09:02 +0100,
>>> Yicong Yang <yangyicong at 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.
> 

I'd vote for 2nd solution. this is only the exception case unless trigger it
purposely, the instructions are used for device memory in the normal
cases. It's unfair to forbid the use of it on LS64WB lacked platforms and we
do support LS64 but no LS64WB.

Injecting the UAoEF back will make the handling consistent with host.

thanks.