From: Peter Maydell <peter.maydell@linaro.org>
To: Richard Henderson <richard.henderson@linaro.org>
Cc: qemu-devel@nongnu.org, qemu-arm@nongnu.org
Subject: Re: [PATCH v3 6/6] target/arm: Do memory type alignment check when translation enabled
Date: Mon, 4 Mar 2024 17:10:55 +0000 [thread overview]
Message-ID: <CAFEAcA-RCuHCR18q6V+xGi_igE-7-+PUrX1eOjduJeeeWFq7EA@mail.gmail.com> (raw)
In-Reply-To: <20240301204110.656742-7-richard.henderson@linaro.org>
On Fri, 1 Mar 2024 at 20:42, Richard Henderson
<richard.henderson@linaro.org> wrote:
>
> If translation is enabled, and the PTE memory type is Device,
> enable checking alignment via TLB_CHECK_ALIGNMENT. While the
> check is done later than it should be per the ARM, it's better
> than not performing the check at all.
>
> Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
> + /*
> + * Enable alignment checks on Device memory.
> + *
> + * Per R_XCHFJ, this check is mis-ordered, in that this alignment check
> + * should have priority 30, while the permission check should be next at
> + * priority 31 and stage2 translation faults come after that.
> + * Due to the way the TCG softmmu TLB operates, we will have implicitly
> + * done the permission check and the stage2 lookup in finding the TLB
> + * entry, so the alignment check cannot be done sooner.
> + */
Looks like in rev J.a the priority list has had some extra entries
added, so these are now items 35, 36 and 37 in the list.
Maybe we should drop the numbering and say
* Per R_XCHFJ, this check is mis-ordered. The correct ordering
* for alignment, permission, and stage 2 faults should be:
* - Alignment fault caused by the memory type
* - Permission fault
* - A stage 2 fault on the memory access
* but due to ...
?
> + if (device) {
> + result->f.tlb_fill_flags |= TLB_CHECK_ALIGNED;
> }
In v7, the alignment faults on Device memory accesses are only
architecturally required if the CPU implements the Virtualization
Extensions; otherwise they are UNPREDICTABLE. But in practice
QEMU doesn't implement any CPU types with ARM_FEATURE_LPAE
but not ARM_FEATURE_V7VE, and "take an alignment fault" is
something that the UNPREDICTABLE case allows us to do, so
it doesn't seem necessary to put in a check for ARM_FEATURE_LPAE
here. We could mention it in the comment, though.
I propose to fold in this comment diff and take the patchset into
target-arm.next:
--- a/target/arm/ptw.c
+++ b/target/arm/ptw.c
@@ -2141,12 +2141,19 @@ static bool get_phys_addr_lpae(CPUARMState
*env, S1Translate *ptw,
/*
* Enable alignment checks on Device memory.
*
- * Per R_XCHFJ, this check is mis-ordered, in that this alignment check
- * should have priority 30, while the permission check should be next at
- * priority 31 and stage2 translation faults come after that.
- * Due to the way the TCG softmmu TLB operates, we will have implicitly
- * done the permission check and the stage2 lookup in finding the TLB
- * entry, so the alignment check cannot be done sooner.
+ * Per R_XCHFJ, this check is mis-ordered. The correct ordering
+ * for alignment, permission, and stage 2 faults should be:
+ * - Alignment fault caused by the memory type
+ * - Permission fault
+ * - A stage 2 fault on the memory access
+ * but due to the way the TCG softmmu TLB operates, we will have
+ * implicitly done the permission check and the stage2 lookup in
+ * finding the TLB entry, so the alignment check cannot be done sooner.
+ *
+ * In v7, for a CPU without the Virtualization Extensions this
+ * access is UNPREDICTABLE; we choose to make it take the alignment
+ * fault as is required for a v7VE CPU. (QEMU doesn't emulate any
+ * CPUs with ARM_FEATURE_LPAE but not ARM_FEATURE_V7VE anyway.)
*/
if (device) {
result->f.tlb_fill_flags |= TLB_CHECK_ALIGNED;
thanks
-- PMM
next prev parent reply other threads:[~2024-03-04 17:11 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-03-01 20:41 [PATCH v3 0/6] target/arm: Do memory alignment check for device memory Richard Henderson
2024-03-01 20:41 ` [PATCH v3 1/6] target/arm: Support 32-byte alignment in pow2_align Richard Henderson
2024-03-01 20:41 ` [PATCH v3 2/6] exec/memattrs: Remove target_tlb_bit* Richard Henderson
2024-03-01 20:41 ` [PATCH v3 3/6] accel/tcg: Add tlb_fill_flags to CPUTLBEntryFull Richard Henderson
2024-03-01 20:41 ` [PATCH v3 4/6] accel/tcg: Add TLB_CHECK_ALIGNED Richard Henderson
2024-03-01 20:41 ` [PATCH v3 5/6] target/arm: Do memory type alignment check when translation disabled Richard Henderson
2024-04-16 15:11 ` Jonathan Cameron via
2024-04-17 20:07 ` Richard Henderson
2024-04-18 8:15 ` Jonathan Cameron via
2024-04-18 17:40 ` Jonathan Cameron via
2024-04-19 11:52 ` [edk2-devel] " Gerd Hoffmann
2024-04-19 16:09 ` Jonathan Cameron via
2024-04-19 16:36 ` Ard Biesheuvel
2024-04-19 17:38 ` Ard Biesheuvel
2024-04-22 15:26 ` Clément Chigot
2024-04-22 15:47 ` Richard Henderson
2024-04-22 15:59 ` Peter Maydell
2024-03-01 20:41 ` [PATCH v3 6/6] target/arm: Do memory type alignment check when translation enabled Richard Henderson
2024-03-04 17:10 ` Peter Maydell [this message]
2024-03-04 17:27 ` Richard Henderson
2024-03-04 17:12 ` [PATCH v3 0/6] target/arm: Do memory alignment check for device memory Peter Maydell
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CAFEAcA-RCuHCR18q6V+xGi_igE-7-+PUrX1eOjduJeeeWFq7EA@mail.gmail.com \
--to=peter.maydell@linaro.org \
--cc=qemu-arm@nongnu.org \
--cc=qemu-devel@nongnu.org \
--cc=richard.henderson@linaro.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).