[PATCH v2 6/6] KVM: arm64: Handle DABT caused by LS64* instructions on unsupported memory

[Yicong Yang]

On 2025/4/2 0:13, Oliver Upton wrote:
> Hi Yicong,
> 
> On Mon, Mar 31, 2025 at 05:43:20PM +0800, Yicong Yang wrote:
>> From: Yicong Yang <yangyicong at 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.
> 

will drop the quote here.

>> 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.

will make this patch ahead.

> 
>> @@ -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.
> 

ok will drop the log here and only inject a DABT back.

> 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.
> 

got it. 0x35 should be caused by LS64* or IMPLEMENTATION DEFINED fault, but no
further hint to distinguish between these two faults. hope it's also the right
behaviour to inject a DABT back for the latter case.

>> @@ -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.
> 

Here's handling the case for emulated mmio, I thought there's no valid stage-2 mapping
for the emulated MMIO? so this check is put just before entering io_mem_abort(). should
it be put into io_mem_abort() or we just don't handle the emulated case?

For the case where's a valid stage-2 mapping, the LS64 DABT is handled in user_mem_abort().

Thanks.