From: "Alex Bennée" <alex.bennee@linaro.org>
To: Helge Deller <deller@kernel.org>
Cc: Richard Henderson <richard.henderson@linaro.org>,
qemu-devel@nongnu.org, linux-parisc@vger.kernel.org
Subject: Re: {PATCH] accel/tcg: Fix CPU specific unaligned behaviour
Date: Wed, 02 Oct 2024 16:35:06 +0100 [thread overview]
Message-ID: <87cykimsb9.fsf@draig.linaro.org> (raw)
In-Reply-To: <Zvyx1kM4JljbzxQW@p100> (Helge Deller's message of "Wed, 2 Oct 2024 04:37:10 +0200")
Helge Deller <deller@kernel.org> writes:
> When the emulated CPU reads or writes to a memory location
> a) for which no read/write permissions exists, *and*
> b) the access happens unaligned (non-natural alignment),
> then the CPU should either
> - trigger a permission fault, or
> - trigger an unalign access fault.
>
> In the current code the alignment check happens before the memory
> permission checks, so only unalignment faults will be triggered.
>
> This behaviour breaks the emulation of the PARISC architecture, where the CPU
> does a memory verification first. The behaviour can be tested with the testcase
> from the bugzilla report.
>
> Add the necessary code to allow PARISC and possibly other architectures to
> trigger a memory fault instead.
>
> Signed-off-by: Helge Deller <deller@gmx.de>
> Fixes: https://bugzilla.kernel.org/show_bug.cgi?id=219339
>
>
> diff --git a/accel/tcg/cputlb.c b/accel/tcg/cputlb.c
> index 117b516739..dd1da358fb 100644
> --- a/accel/tcg/cputlb.c
> +++ b/accel/tcg/cputlb.c
> @@ -1684,6 +1684,26 @@ static void mmu_watch_or_dirty(CPUState *cpu, MMULookupPageData *data,
> data->flags = flags;
> }
>
> +/* when accessing unreadable memory unaligned, will the CPU issue
> + * a alignment trap or a memory access trap ? */
> +#ifdef TARGET_HPPA
> +# define CPU_ALIGNMENT_CHECK_AFTER_MEMCHECK 1
> +#else
> +# define CPU_ALIGNMENT_CHECK_AFTER_MEMCHECK 0
> +#endif
I'm pretty certain we don't want to be introducing per-guest hacks into
the core cputlb.c code when we are aiming to make it a compile once
object.
I guess the real question is where could we put this flag? My gut says
we should expand the MO_ALIGN bits in MemOp to express the precedence or
not of the alignment check in relation to permissions.
> +
> +static void mmu_check_alignment(CPUState *cpu, vaddr addr,
> + uintptr_t ra, MMUAccessType type, MMULookupLocals *l)
> +{
> + unsigned a_bits;
> +
> + /* Handle CPU specific unaligned behaviour */
> + a_bits = get_alignment_bits(l->memop);
> + if (addr & ((1 << a_bits) - 1)) {
> + cpu_unaligned_access(cpu, addr, type, l->mmu_idx, ra);
> + }
> +}
> +
> /**
> * mmu_lookup: translate page(s)
> * @cpu: generic cpu state
> @@ -1699,7 +1719,6 @@ static void mmu_watch_or_dirty(CPUState *cpu, MMULookupPageData *data,
> static bool mmu_lookup(CPUState *cpu, vaddr addr, MemOpIdx oi,
> uintptr_t ra, MMUAccessType type, MMULookupLocals *l)
> {
> - unsigned a_bits;
> bool crosspage;
> int flags;
>
> @@ -1708,10 +1727,8 @@ static bool mmu_lookup(CPUState *cpu, vaddr addr, MemOpIdx oi,
>
> tcg_debug_assert(l->mmu_idx < NB_MMU_MODES);
>
> - /* Handle CPU specific unaligned behaviour */
> - a_bits = get_alignment_bits(l->memop);
> - if (addr & ((1 << a_bits) - 1)) {
> - cpu_unaligned_access(cpu, addr, type, l->mmu_idx, ra);
> + if (!CPU_ALIGNMENT_CHECK_AFTER_MEMCHECK) {
Then this would be something like:
if (!(memop & MO_ALIGN_PP)) or something
> + mmu_check_alignment(cpu, addr, ra, type, l);
> }
>
> l->page[0].addr = addr;
> @@ -1760,6 +1777,10 @@ static bool mmu_lookup(CPUState *cpu, vaddr addr, MemOpIdx oi,
> tcg_debug_assert((flags & TLB_BSWAP) == 0);
> }
>
> + if (CPU_ALIGNMENT_CHECK_AFTER_MEMCHECK) {
> + mmu_check_alignment(cpu, addr, ra, type, l);
> + }
> +
> /*
> * This alignment check differs from the one above, in that this is
> * based on the atomicity of the operation. The intended use case is
--
Alex Bennée
Virtualisation Tech Lead @ Linaro
next prev parent reply other threads:[~2024-10-02 15:35 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-10-02 2:37 {PATCH] accel/tcg: Fix CPU specific unaligned behaviour Helge Deller
2024-10-02 15:35 ` Alex Bennée [this message]
2024-10-02 15:47 ` Peter Maydell
2024-10-02 17:25 ` Alex Bennée
2024-10-02 19:38 ` Helge Deller
2024-10-03 23:08 ` Richard Henderson
2024-10-04 14:24 ` Richard Henderson
2024-10-05 16:55 ` Richard Henderson
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=87cykimsb9.fsf@draig.linaro.org \
--to=alex.bennee@linaro.org \
--cc=deller@kernel.org \
--cc=linux-parisc@vger.kernel.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.