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