[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH v2 1/6] linux-user/aarch64: Extend PR_SET_TAGGED_ADDR_CTRL fo
From: |
Richard Henderson |
Subject: |
Re: [PATCH v2 1/6] linux-user/aarch64: Extend PR_SET_TAGGED_ADDR_CTRL for FEAT_MTE3 |
Date: |
Wed, 7 Feb 2024 10:31:42 +1000 |
User-agent: |
Mozilla Thunderbird |
On 2/7/24 00:23, Peter Maydell wrote:
On Tue, 6 Feb 2024 at 03:06, Richard Henderson
<richard.henderson@linaro.org> wrote:
When MTE3 is supported, the kernel maps
PR_MTE_TCF_ASYNC | PR_MTE_TCF_SYNC
to
MTE_CTRL_TCF_ASYMM
and from there to
SCTLR_EL1.TCF0 = 3
This depends on the setting of
/sys/devices/system/cpu/cpu<N>/mte_tcf_preferred :
I think you only get asymm here if the sysadmin has set
mte_tcf_preferred to 'asymm'; the default is 'async'.
Hmm, I missed that somewhere in the rat's nest.
I suspect this is over-engineered, such that no one will understand how to use
it.
For QEMU's implementation, are there any particular
performance differences between sync, async and asymm ?
I doubt it. Getting to the error path at all is the bulk of the work.
I think "performance" in this case would be highly test-case-centric.
Does the test "perform better" with async, which would allow the entire vector operation
to finish in one go?
I suspect that for debugging purposes, sync is always preferred.
That might be the best setting for qemu.
r~
- [PATCH v2 0/6] target/arm: assorted mte fixes, Richard Henderson, 2024/02/05
- [PATCH v2 1/6] linux-user/aarch64: Extend PR_SET_TAGGED_ADDR_CTRL for FEAT_MTE3, Richard Henderson, 2024/02/05
- [PATCH v2 5/6] target/arm: Handle mte in do_ldrq, do_ldro, Richard Henderson, 2024/02/05
- [PATCH v2 2/6] target/arm: Fix nregs computation in do_ld_zpa, Richard Henderson, 2024/02/05
- [PATCH v2 4/6] target/arm: Split out make_svemte_desc, Richard Henderson, 2024/02/05
- [PATCH v2 3/6] target/arm: Adjust and validate mtedesc sizem1, Richard Henderson, 2024/02/05