[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAL715WKaAHSgUhtMMT3Ztw90mMoHpVLdKUgVM15xx6yoUws9+Q@mail.gmail.com>
Date: Fri, 4 Apr 2025 17:31:49 -0700
From: Mingwei Zhang <mizhang@...gle.com>
To: Raghavendra Rao Ananta <rananta@...gle.com>
Cc: Oliver Upton <oliver.upton@...ux.dev>, Marc Zyngier <maz@...nel.org>,
linux-arm-kernel@...ts.infradead.org, kvmarm@...ts.linux.dev,
linux-kernel@...r.kernel.org, kvm@...r.kernel.org,
Oliver Upton <oupton@...gle.com>
Subject: Re: [PATCH v2 2/2] KVM: selftests: arm64: Explicitly set the page
attrs to Inner-Shareable
.
On Fri, Apr 4, 2025 at 5:10 PM Raghavendra Rao Ananta
<rananta@...gle.com> wrote:
>
> Atomic instructions such as 'ldset' over (global) variables in the guest
> is observed to cause an EL1 data abort with FSC 0x35 (IMPLEMENTATION
> DEFINED fault (Unsupported Exclusive or Atomic access)). The observation
> was particularly apparent on Neoverse-N3.
>
> According to ARM ARM DDI0487L.a B2.2.6 (Possible implementation
> restrictions on using atomic instructions), atomic instructions are
> architecturally guaranteed for Inner Shareable and Outer Shareable
> attributes. For Non-Shareable attribute, the atomic instructions are
> not atomic and issuing such an instruction can lead to the FSC
> mentioned in this case (among other things).
>
> Moreover, according to DDI0487L.a C3.2.6 (Single-copy atomic 64-byte
> load/store), it is implementation defined that a data abort with the
> mentioned FSC is reported for the first stage of translation that
> provides an inappropriate memory type. It's likely that Neoverse-N3
> chose to implement these two and why we see an FSC of 0x35 in EL1 upon
> executing atomic instructions.
nit: It's likely that Neoverse-N3 chose to implement this option (the
first option) instead of reporting at the final enabled stage of
translation
I have minor question here: The DDI0487L C3.2.6 (Single-copy atomic
64-byte load/store) mentioned
"""
When the instructions access a memory type that is not one of the
following, a data abort for unsupported Exclusive or atomic access is
generated:
• Normal Inner Non-cacheable, Outer Non-cacheable.
"""
So, the above is the "Normal Inner Non-cacheable", but in our case we
have "Normal and non-shareable" in stage-1 mapping, right? I know it
is very close, but it seems the situation is still only "one bit" away
in my understanding...
>
> ARM64 KVM selftests sets no shareable attributes, which makes them
> Non-Shareable by default. Hence, explicitly set them as Inner-Shareable
> to fix this issue.
>
> Suggested-by: Oliver Upton <oupton@...gle.com>
> Signed-off-by: Raghavendra Rao Ananta <rananta@...gle.com>
> ---
> tools/testing/selftests/kvm/include/arm64/processor.h | 1 +
> tools/testing/selftests/kvm/lib/arm64/processor.c | 3 +++
> 2 files changed, 4 insertions(+)
>
> diff --git a/tools/testing/selftests/kvm/include/arm64/processor.h b/tools/testing/selftests/kvm/include/arm64/processor.h
> index 7d88ff22013a..b0fc0f945766 100644
> --- a/tools/testing/selftests/kvm/include/arm64/processor.h
> +++ b/tools/testing/selftests/kvm/include/arm64/processor.h
> @@ -113,6 +113,7 @@
> #define PMD_TYPE_TABLE BIT(1)
> #define PTE_TYPE_PAGE BIT(1)
>
> +#define PTE_SHARED (UL(3) << 8) /* SH[1:0], inner shareable */
> #define PTE_AF BIT(10)
>
> #define PTE_ADDR_MASK(page_shift) GENMASK(47, (page_shift))
> diff --git a/tools/testing/selftests/kvm/lib/arm64/processor.c b/tools/testing/selftests/kvm/lib/arm64/processor.c
> index da5802c8a59c..9d69904cb608 100644
> --- a/tools/testing/selftests/kvm/lib/arm64/processor.c
> +++ b/tools/testing/selftests/kvm/lib/arm64/processor.c
> @@ -172,6 +172,9 @@ static void _virt_pg_map(struct kvm_vm *vm, uint64_t vaddr, uint64_t paddr,
> }
>
> pg_attr = PTE_AF | PTE_ATTRINDX(attr_idx) | PTE_TYPE_PAGE | PTE_VALID;
> + if (!use_lpa2_pte_format(vm))
> + pg_attr |= PTE_SHARED;
> +
> *ptep = addr_pte(vm, paddr, pg_attr);
> }
>
> --
> 2.49.0.504.g3bcea36a83-goog
>
Powered by blists - more mailing lists