Re: [ARM64] status of MTE selftests?

Re: [ARM64] status of MTE selftests?

[Cornelia Huck]

[memo to self: don't send stuff on Friday evenings]

Sorry about the spam, resend w/o config, see
https://people.redhat.com/~cohuck/config-mte

On Fri, May 06 2022, Cornelia Huck <cohuck@redhat.com> wrote:

> Hi,
>
> I'm currently trying to run the MTE selftests on the FVP simulator (Base
> Model)[1], mainly to verify things are sane on the host before wiring up
> the KVM support in QEMU. However, I'm seeing some failures (the non-mte
> tests seemed all fine):
>
> # selftests: /arm64: check_buffer_fill
> # 1..20
> # ok 1 Check buffer correctness by byte with sync err mode and mmap memory
> # ok 2 Check buffer correctness by byte with async err mode and mmap memory
> # ok 3 Check buffer correctness by byte with sync err mode and mmap/mprotect memory
> # ok 4 Check buffer correctness by byte with async err mode and mmap/mprotect memory
> # not ok 5 Check buffer write underflow by byte with sync mode and mmap memory
> # not ok 6 Check buffer write underflow by byte with async mode and mmap memory
> # ok 7 Check buffer write underflow by byte with tag check fault ignore and mmap memory
> # not ok 8 Check buffer write underflow by byte with sync mode and mmap memory
> # not ok 9 Check buffer write underflow by byte with async mode and mmap memory
> # ok 10 Check buffer write underflow by byte with tag check fault ignore and mmap memory
> # not ok 11 Check buffer write overflow by byte with sync mode and mmap memory
> # not ok 12 Check buffer write overflow by byte with async mode and mmap memory
> # ok 13 Check buffer write overflow by byte with tag fault ignore mode and mmap memory
> # ok 14 Check buffer write correctness by block with sync mode and mmap memory
> # ok 15 Check buffer write correctness by block with async mode and mmap memory
> # ok 16 Check buffer write correctness by block with tag fault ignore and mmap memory
> # ok 17 Check initial tags with private mapping, sync error mode and mmap memory
> # ok 18 Check initial tags with private mapping, sync error mode and mmap/mprotect memory
> # ok 19 Check initial tags with shared mapping, sync error mode and mmap memory
> # ok 20 Check initial tags with shared mapping, sync error mode and mmap/mprotect memory
> # # Totals: pass:14 fail:6 xfail:0 xpass:0 skip:0 error:0
> not ok 24 selftests: /arm64: check_buffer_fill # exit=1
>
> # selftests: /arm64: check_child_memory
> # 1..12
> # not ok 1 Check child anonymous memory with private mapping, precise mode and mmap memory
> # not ok 2 Check child anonymous memory with shared mapping, precise mode and mmap memory
> # not ok 3 Check child anonymous memory with private mapping, imprecise mode and mmap memory
> # not ok 4 Check child anonymous memory with shared mapping, imprecise mode and mmap memory
> # not ok 5 Check child anonymous memory with private mapping, precise mode and mmap/mprotect memory
> # not ok 6 Check child anonymous memory with shared mapping, precise mode and mmap/mprotect memory
> # not ok 7 Check child file memory with private mapping, precise mode and mmap memory
> # not ok 8 Check child file memory with shared mapping, precise mode and mmap memory
> # not ok 9 Check child file memory with private mapping, imprecise mode and mmap memory
> # not ok 10 Check child file memory with shared mapping, imprecise mode and mmap memory
> # not ok 11 Check child file memory with private mapping, precise mode and mmap/mprotect memory
> # not ok 12 Check child file memory with shared mapping, precise mode and mmap/mprotect memory
> # # Totals: pass:0 fail:12 xfail:0 xpass:0 skip:0 error:0
> not ok 25 selftests: /arm64: check_child_memory # exit=1
>
> # selftests: /arm64: check_gcr_el1_cswitch
> # 1..1
> # 1..1
> # 1..1
> # 1..1
> [...many more lines of the same...]
> # 1..1
> #
> not ok 26 selftests: /arm64: check_gcr_el1_cswitch # TIMEOUT 45 seconds
>
> # selftests: /arm64: check_mmap_options
> # 1..22
> # ok 1 Check anonymous memory with private mapping, sync error mode, mmap memory and tag check off
> # ok 2 Check file memory with private mapping, sync error mode, mmap/mprotect memory and tag check off
> # ok 3 Check anonymous memory with private mapping, no error mode, mmap memory and tag check off
> # ok 4 Check file memory with private mapping, no error mode, mmap/mprotect memory and tag check off
> # not ok 5 Check anonymous memory with private mapping, sync error mode, mmap memory and tag check on
> # not ok 6 Check anonymous memory with private mapping, sync error mode, mmap/mprotect memory and tag check on
> # not ok 7 Check anonymous memory with shared mapping, sync error mode, mmap memory and tag check on
> # not ok 8 Check anonymous memory with shared mapping, sync error mode, mmap/mprotect memory and tag check on
> # not ok 9 Check anonymous memory with private mapping, async error mode, mmap memory and tag check on
> # not ok 10 Check anonymous memory with private mapping, async error mode, mmap/mprotect memory and tag check on
> # not ok 11 Check anonymous memory with shared mapping, async error mode, mmap memory and tag check on
> # not ok 12 Check anonymous memory with shared mapping, async error mode, mmap/mprotect memory and tag check on
> # not ok 13 Check file memory with private mapping, sync error mode, mmap memory and tag check on
> # not ok 14 Check file memory with private mapping, sync error mode, mmap/mprotect memory and tag check on
> # not ok 15 Check file memory with shared mapping, sync error mode, mmap memory and tag check on
> # not ok 16 Check file memory with shared mapping, sync error mode, mmap/mprotect memory and tag check on
> # not ok 17 Check file memory with private mapping, async error mode, mmap memory and tag check on
> # not ok 18 Check file memory with private mapping, async error mode, mmap/mprotect memory and tag check on
> # not ok 19 Check file memory with shared mapping, async error mode, mmap memory and tag check on
> # not ok 20 Check file memory with shared mapping, async error mode, mmap/mprotect memory and tag check on
> # not ok 21 Check clear PROT_MTE flags with private mapping, sync error mode and mmap memory
> # not ok 22 Check clear PROT_MTE flags with private mapping and sync error mode and mmap/mprotect memory
> # # Totals: pass:4 fail:18 xfail:0 xpass:0 skip:0 error:0
> not ok 28 selftests: /arm64: check_mmap_options # exit=1
>
> # selftests: /arm64: check_tags_inclusion
> # 1..4
> # not ok 1 Check an included tag value with sync mode
> # not ok 2 Check different included tags value with sync mode
> # ok 3 Check none included tags value with sync mode
> # not ok 4 Check all included tags value with sync mode
> # # Totals: pass:1 fail:3 xfail:0 xpass:0 skip:0 error:0
> not ok 29 selftests: /arm64: check_tags_inclusion # exit=1
>
> check_ksm_options and check_user_mem work as expected.
>
> Are the MTE tests supposed to work on the FVP model? Something broken in
> my config? Anything I can debug?
>
> [1] Command line:
> "$MODEL" \
> -C cache_state_modelled=0 \
> -C bp.refcounter.non_arch_start_at_default=1 \
> -C bp.secure_memory=false \
> -C cluster0.has_arm_v8-1=1 \
> -C cluster0.has_arm_v8-2=1 \
> -C cluster0.has_arm_v8-3=1 \
> -C cluster0.has_arm_v8-4=1 \
> -C cluster0.has_arm_v8-5=1 \
> -C cluster0.has_amu=1 \
> -C cluster0.NUM_CORES=4 \
> -C cluster0.memory_tagging_support_level=2 \
> -a "cluster0.*=$AXF" \
>
> where $AXF contains a kernel at v5.18-rc5-16-g107c948d1d3e[2] and an
> initrd built by mbuto[3] from that level with a slightly tweaked "kselftests"
> profile (adding /dev/shm).
>
> [2] CONFIG_ARM64_MTE=y, no modules; complete config below[4]
>
> [3] https://mbuto.sh/mbuto/
>
> [4] kernel config: https://people.redhat.com/~cohuck/config-mte

Re: [ARM64] status of MTE selftests?

[Cornelia Huck]

[memo to self: don't send stuff on Friday evenings]

Sorry about the spam, resend w/o config, see
https://people.redhat.com/~cohuck/config-mte

On Fri, May 06 2022, Cornelia Huck <cohuck@redhat.com> wrote:

> Hi,
>
> I'm currently trying to run the MTE selftests on the FVP simulator (Base
> Model)[1], mainly to verify things are sane on the host before wiring up
> the KVM support in QEMU. However, I'm seeing some failures (the non-mte
> tests seemed all fine):
>
> # selftests: /arm64: check_buffer_fill
> # 1..20
> # ok 1 Check buffer correctness by byte with sync err mode and mmap memory
> # ok 2 Check buffer correctness by byte with async err mode and mmap memory
> # ok 3 Check buffer correctness by byte with sync err mode and mmap/mprotect memory
> # ok 4 Check buffer correctness by byte with async err mode and mmap/mprotect memory
> # not ok 5 Check buffer write underflow by byte with sync mode and mmap memory
> # not ok 6 Check buffer write underflow by byte with async mode and mmap memory
> # ok 7 Check buffer write underflow by byte with tag check fault ignore and mmap memory
> # not ok 8 Check buffer write underflow by byte with sync mode and mmap memory
> # not ok 9 Check buffer write underflow by byte with async mode and mmap memory
> # ok 10 Check buffer write underflow by byte with tag check fault ignore and mmap memory
> # not ok 11 Check buffer write overflow by byte with sync mode and mmap memory
> # not ok 12 Check buffer write overflow by byte with async mode and mmap memory
> # ok 13 Check buffer write overflow by byte with tag fault ignore mode and mmap memory
> # ok 14 Check buffer write correctness by block with sync mode and mmap memory
> # ok 15 Check buffer write correctness by block with async mode and mmap memory
> # ok 16 Check buffer write correctness by block with tag fault ignore and mmap memory
> # ok 17 Check initial tags with private mapping, sync error mode and mmap memory
> # ok 18 Check initial tags with private mapping, sync error mode and mmap/mprotect memory
> # ok 19 Check initial tags with shared mapping, sync error mode and mmap memory
> # ok 20 Check initial tags with shared mapping, sync error mode and mmap/mprotect memory
> # # Totals: pass:14 fail:6 xfail:0 xpass:0 skip:0 error:0
> not ok 24 selftests: /arm64: check_buffer_fill # exit=1
>
> # selftests: /arm64: check_child_memory
> # 1..12
> # not ok 1 Check child anonymous memory with private mapping, precise mode and mmap memory
> # not ok 2 Check child anonymous memory with shared mapping, precise mode and mmap memory
> # not ok 3 Check child anonymous memory with private mapping, imprecise mode and mmap memory
> # not ok 4 Check child anonymous memory with shared mapping, imprecise mode and mmap memory
> # not ok 5 Check child anonymous memory with private mapping, precise mode and mmap/mprotect memory
> # not ok 6 Check child anonymous memory with shared mapping, precise mode and mmap/mprotect memory
> # not ok 7 Check child file memory with private mapping, precise mode and mmap memory
> # not ok 8 Check child file memory with shared mapping, precise mode and mmap memory
> # not ok 9 Check child file memory with private mapping, imprecise mode and mmap memory
> # not ok 10 Check child file memory with shared mapping, imprecise mode and mmap memory
> # not ok 11 Check child file memory with private mapping, precise mode and mmap/mprotect memory
> # not ok 12 Check child file memory with shared mapping, precise mode and mmap/mprotect memory
> # # Totals: pass:0 fail:12 xfail:0 xpass:0 skip:0 error:0
> not ok 25 selftests: /arm64: check_child_memory # exit=1
>
> # selftests: /arm64: check_gcr_el1_cswitch
> # 1..1
> # 1..1
> # 1..1
> # 1..1
> [...many more lines of the same...]
> # 1..1
> #
> not ok 26 selftests: /arm64: check_gcr_el1_cswitch # TIMEOUT 45 seconds
>
> # selftests: /arm64: check_mmap_options
> # 1..22
> # ok 1 Check anonymous memory with private mapping, sync error mode, mmap memory and tag check off
> # ok 2 Check file memory with private mapping, sync error mode, mmap/mprotect memory and tag check off
> # ok 3 Check anonymous memory with private mapping, no error mode, mmap memory and tag check off
> # ok 4 Check file memory with private mapping, no error mode, mmap/mprotect memory and tag check off
> # not ok 5 Check anonymous memory with private mapping, sync error mode, mmap memory and tag check on
> # not ok 6 Check anonymous memory with private mapping, sync error mode, mmap/mprotect memory and tag check on
> # not ok 7 Check anonymous memory with shared mapping, sync error mode, mmap memory and tag check on
> # not ok 8 Check anonymous memory with shared mapping, sync error mode, mmap/mprotect memory and tag check on
> # not ok 9 Check anonymous memory with private mapping, async error mode, mmap memory and tag check on
> # not ok 10 Check anonymous memory with private mapping, async error mode, mmap/mprotect memory and tag check on
> # not ok 11 Check anonymous memory with shared mapping, async error mode, mmap memory and tag check on
> # not ok 12 Check anonymous memory with shared mapping, async error mode, mmap/mprotect memory and tag check on
> # not ok 13 Check file memory with private mapping, sync error mode, mmap memory and tag check on
> # not ok 14 Check file memory with private mapping, sync error mode, mmap/mprotect memory and tag check on
> # not ok 15 Check file memory with shared mapping, sync error mode, mmap memory and tag check on
> # not ok 16 Check file memory with shared mapping, sync error mode, mmap/mprotect memory and tag check on
> # not ok 17 Check file memory with private mapping, async error mode, mmap memory and tag check on
> # not ok 18 Check file memory with private mapping, async error mode, mmap/mprotect memory and tag check on
> # not ok 19 Check file memory with shared mapping, async error mode, mmap memory and tag check on
> # not ok 20 Check file memory with shared mapping, async error mode, mmap/mprotect memory and tag check on
> # not ok 21 Check clear PROT_MTE flags with private mapping, sync error mode and mmap memory
> # not ok 22 Check clear PROT_MTE flags with private mapping and sync error mode and mmap/mprotect memory
> # # Totals: pass:4 fail:18 xfail:0 xpass:0 skip:0 error:0
> not ok 28 selftests: /arm64: check_mmap_options # exit=1
>
> # selftests: /arm64: check_tags_inclusion
> # 1..4
> # not ok 1 Check an included tag value with sync mode
> # not ok 2 Check different included tags value with sync mode
> # ok 3 Check none included tags value with sync mode
> # not ok 4 Check all included tags value with sync mode
> # # Totals: pass:1 fail:3 xfail:0 xpass:0 skip:0 error:0
> not ok 29 selftests: /arm64: check_tags_inclusion # exit=1
>
> check_ksm_options and check_user_mem work as expected.
>
> Are the MTE tests supposed to work on the FVP model? Something broken in
> my config? Anything I can debug?
>
> [1] Command line:
> "$MODEL" \
> -C cache_state_modelled=0 \
> -C bp.refcounter.non_arch_start_at_default=1 \
> -C bp.secure_memory=false \
> -C cluster0.has_arm_v8-1=1 \
> -C cluster0.has_arm_v8-2=1 \
> -C cluster0.has_arm_v8-3=1 \
> -C cluster0.has_arm_v8-4=1 \
> -C cluster0.has_arm_v8-5=1 \
> -C cluster0.has_amu=1 \
> -C cluster0.NUM_CORES=4 \
> -C cluster0.memory_tagging_support_level=2 \
> -a "cluster0.*=$AXF" \
>
> where $AXF contains a kernel at v5.18-rc5-16-g107c948d1d3e[2] and an
> initrd built by mbuto[3] from that level with a slightly tweaked "kselftests"
> profile (adding /dev/shm).
>
> [2] CONFIG_ARM64_MTE=y, no modules; complete config below[4]
>
> [3] https://mbuto.sh/mbuto/
>
> [4] kernel config: https://people.redhat.com/~cohuck/config-mte


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [ARM64] status of MTE selftests?

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 1443 bytes --]

On Fri, May 06, 2022 at 04:50:41PM +0200, Cornelia Huck wrote:

> I'm currently trying to run the MTE selftests on the FVP simulator (Base
> Model)[1], mainly to verify things are sane on the host before wiring up
> the KVM support in QEMU. However, I'm seeing some failures (the non-mte
> tests seemed all fine):

> Are the MTE tests supposed to work on the FVP model? Something broken in
> my config? Anything I can debug?

I would expect them to work, they seemed happy when I was doing
the async mode support IIRC and a quick spin with -next in qemu
everything seems fine, I'm travelling so don't have the
environment for models to hand right now.

> [1] Command line:
> "$MODEL" \
> -C cache_state_modelled=0 \
> -C bp.refcounter.non_arch_start_at_default=1 \
> -C bp.secure_memory=false \
> -C cluster0.has_arm_v8-1=1 \
> -C cluster0.has_arm_v8-2=1 \
> -C cluster0.has_arm_v8-3=1 \
> -C cluster0.has_arm_v8-4=1 \
> -C cluster0.has_arm_v8-5=1 \
> -C cluster0.has_amu=1 \
> -C cluster0.NUM_CORES=4 \
> -C cluster0.memory_tagging_support_level=2 \
> -a "cluster0.*=$AXF" \

> where $AXF contains a kernel at v5.18-rc5-16-g107c948d1d3e[2] and an
> initrd built by mbuto[3] from that level with a slightly tweaked "kselftests"
> profile (adding /dev/shm).

What are you using for EL3 with the model?  Both TF-A and
boot-wrapper are in regular use, TF-A gets *way* more testing
than boot-wrapper which is mostly used by individual developers.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: [ARM64] status of MTE selftests?

[Mark Brown]

[-- Attachment #1.1: Type: text/plain, Size: 1443 bytes --]

On Fri, May 06, 2022 at 04:50:41PM +0200, Cornelia Huck wrote:

> I'm currently trying to run the MTE selftests on the FVP simulator (Base
> Model)[1], mainly to verify things are sane on the host before wiring up
> the KVM support in QEMU. However, I'm seeing some failures (the non-mte
> tests seemed all fine):

> Are the MTE tests supposed to work on the FVP model? Something broken in
> my config? Anything I can debug?

I would expect them to work, they seemed happy when I was doing
the async mode support IIRC and a quick spin with -next in qemu
everything seems fine, I'm travelling so don't have the
environment for models to hand right now.

> [1] Command line:
> "$MODEL" \
> -C cache_state_modelled=0 \
> -C bp.refcounter.non_arch_start_at_default=1 \
> -C bp.secure_memory=false \
> -C cluster0.has_arm_v8-1=1 \
> -C cluster0.has_arm_v8-2=1 \
> -C cluster0.has_arm_v8-3=1 \
> -C cluster0.has_arm_v8-4=1 \
> -C cluster0.has_arm_v8-5=1 \
> -C cluster0.has_amu=1 \
> -C cluster0.NUM_CORES=4 \
> -C cluster0.memory_tagging_support_level=2 \
> -a "cluster0.*=$AXF" \

> where $AXF contains a kernel at v5.18-rc5-16-g107c948d1d3e[2] and an
> initrd built by mbuto[3] from that level with a slightly tweaked "kselftests"
> profile (adding /dev/shm).

What are you using for EL3 with the model?  Both TF-A and
boot-wrapper are in regular use, TF-A gets *way* more testing
than boot-wrapper which is mostly used by individual developers.

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

[-- Attachment #2: Type: text/plain, Size: 176 bytes --]

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [ARM64] status of MTE selftests?

[Cornelia Huck]

On Fri, May 06 2022, Mark Brown <broonie@kernel.org> wrote:

> On Fri, May 06, 2022 at 04:50:41PM +0200, Cornelia Huck wrote:
>
>> I'm currently trying to run the MTE selftests on the FVP simulator (Base
>> Model)[1], mainly to verify things are sane on the host before wiring up
>> the KVM support in QEMU. However, I'm seeing some failures (the non-mte
>> tests seemed all fine):
>
>> Are the MTE tests supposed to work on the FVP model? Something broken in
>> my config? Anything I can debug?
>
> I would expect them to work, they seemed happy when I was doing
> the async mode support IIRC and a quick spin with -next in qemu
> everything seems fine, I'm travelling so don't have the
> environment for models to hand right now.

Thanks; I think that points to some setup/config problem on my side,
then :/ (I ran the selftests under QEMU's tcg emulation, and while it
looks better, I still get timeouts for check_gcr_el1_cswitch and
check_user_mem.)

>
>> [1] Command line:
>> "$MODEL" \
>> -C cache_state_modelled=0 \
>> -C bp.refcounter.non_arch_start_at_default=1 \
>> -C bp.secure_memory=false \
>> -C cluster0.has_arm_v8-1=1 \
>> -C cluster0.has_arm_v8-2=1 \
>> -C cluster0.has_arm_v8-3=1 \
>> -C cluster0.has_arm_v8-4=1 \
>> -C cluster0.has_arm_v8-5=1 \
>> -C cluster0.has_amu=1 \
>> -C cluster0.NUM_CORES=4 \
>> -C cluster0.memory_tagging_support_level=2 \
>> -a "cluster0.*=$AXF" \
>
>> where $AXF contains a kernel at v5.18-rc5-16-g107c948d1d3e[2] and an
>> initrd built by mbuto[3] from that level with a slightly tweaked "kselftests"
>> profile (adding /dev/shm).
>
> What are you using for EL3 with the model?  Both TF-A and
> boot-wrapper are in regular use, TF-A gets *way* more testing
> than boot-wrapper which is mostly used by individual developers.

I'm building the .axf via boot-wrapper-aarch64 (enabling psci and gicv3,
if that matters.) Didn't try to make use of TF-A yet beyond the dtb (I'm
still in the process of getting familiar with the arm64 world, so I'm
currently starting out with the setups that others had shared with me.)

Re: [ARM64] status of MTE selftests?

[Cornelia Huck]

On Fri, May 06 2022, Mark Brown <broonie@kernel.org> wrote:

> On Fri, May 06, 2022 at 04:50:41PM +0200, Cornelia Huck wrote:
>
>> I'm currently trying to run the MTE selftests on the FVP simulator (Base
>> Model)[1], mainly to verify things are sane on the host before wiring up
>> the KVM support in QEMU. However, I'm seeing some failures (the non-mte
>> tests seemed all fine):
>
>> Are the MTE tests supposed to work on the FVP model? Something broken in
>> my config? Anything I can debug?
>
> I would expect them to work, they seemed happy when I was doing
> the async mode support IIRC and a quick spin with -next in qemu
> everything seems fine, I'm travelling so don't have the
> environment for models to hand right now.

Thanks; I think that points to some setup/config problem on my side,
then :/ (I ran the selftests under QEMU's tcg emulation, and while it
looks better, I still get timeouts for check_gcr_el1_cswitch and
check_user_mem.)

>
>> [1] Command line:
>> "$MODEL" \
>> -C cache_state_modelled=0 \
>> -C bp.refcounter.non_arch_start_at_default=1 \
>> -C bp.secure_memory=false \
>> -C cluster0.has_arm_v8-1=1 \
>> -C cluster0.has_arm_v8-2=1 \
>> -C cluster0.has_arm_v8-3=1 \
>> -C cluster0.has_arm_v8-4=1 \
>> -C cluster0.has_arm_v8-5=1 \
>> -C cluster0.has_amu=1 \
>> -C cluster0.NUM_CORES=4 \
>> -C cluster0.memory_tagging_support_level=2 \
>> -a "cluster0.*=$AXF" \
>
>> where $AXF contains a kernel at v5.18-rc5-16-g107c948d1d3e[2] and an
>> initrd built by mbuto[3] from that level with a slightly tweaked "kselftests"
>> profile (adding /dev/shm).
>
> What are you using for EL3 with the model?  Both TF-A and
> boot-wrapper are in regular use, TF-A gets *way* more testing
> than boot-wrapper which is mostly used by individual developers.

I'm building the .axf via boot-wrapper-aarch64 (enabling psci and gicv3,
if that matters.) Didn't try to make use of TF-A yet beyond the dtb (I'm
still in the process of getting familiar with the arm64 world, so I'm
currently starting out with the setups that others had shared with me.)


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [ARM64] status of MTE selftests?

[Cornelia Huck]

On Mon, May 09 2022, Cornelia Huck <cohuck@redhat.com> wrote:

> On Fri, May 06 2022, Mark Brown <broonie@kernel.org> wrote:
>
>> On Fri, May 06, 2022 at 04:50:41PM +0200, Cornelia Huck wrote:
>>
>>> I'm currently trying to run the MTE selftests on the FVP simulator (Base
>>> Model)[1], mainly to verify things are sane on the host before wiring up
>>> the KVM support in QEMU. However, I'm seeing some failures (the non-mte
>>> tests seemed all fine):
>>
>>> Are the MTE tests supposed to work on the FVP model? Something broken in
>>> my config? Anything I can debug?
>>
>> I would expect them to work, they seemed happy when I was doing
>> the async mode support IIRC and a quick spin with -next in qemu
>> everything seems fine, I'm travelling so don't have the
>> environment for models to hand right now.
>
> Thanks; I think that points to some setup/config problem on my side,
> then :/ (I ran the selftests under QEMU's tcg emulation, and while it
> looks better, I still get timeouts for check_gcr_el1_cswitch and
> check_user_mem.)

...so these two tests are simply very slow; if I run them directly, they
take longer than 45s, but eventually finish. So all seems good (in a
slow way) on QEMU + tcg.

On the simulator, running check_gcr_el1_cswitch directly finishes
successfully after several minutes as well; however, I get all the other
failures in tests that I reported in my first mail even when I run them
directly.

Re: [ARM64] status of MTE selftests?

[Cornelia Huck]

On Mon, May 09 2022, Cornelia Huck <cohuck@redhat.com> wrote:

> On Fri, May 06 2022, Mark Brown <broonie@kernel.org> wrote:
>
>> On Fri, May 06, 2022 at 04:50:41PM +0200, Cornelia Huck wrote:
>>
>>> I'm currently trying to run the MTE selftests on the FVP simulator (Base
>>> Model)[1], mainly to verify things are sane on the host before wiring up
>>> the KVM support in QEMU. However, I'm seeing some failures (the non-mte
>>> tests seemed all fine):
>>
>>> Are the MTE tests supposed to work on the FVP model? Something broken in
>>> my config? Anything I can debug?
>>
>> I would expect them to work, they seemed happy when I was doing
>> the async mode support IIRC and a quick spin with -next in qemu
>> everything seems fine, I'm travelling so don't have the
>> environment for models to hand right now.
>
> Thanks; I think that points to some setup/config problem on my side,
> then :/ (I ran the selftests under QEMU's tcg emulation, and while it
> looks better, I still get timeouts for check_gcr_el1_cswitch and
> check_user_mem.)

...so these two tests are simply very slow; if I run them directly, they
take longer than 45s, but eventually finish. So all seems good (in a
slow way) on QEMU + tcg.

On the simulator, running check_gcr_el1_cswitch directly finishes
successfully after several minutes as well; however, I get all the other
failures in tests that I reported in my first mail even when I run them
directly.


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [ARM64] status of MTE selftests?

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 1617 bytes --]

On Mon, May 09, 2022 at 11:59:59AM +0200, Cornelia Huck wrote:
> On Fri, May 06 2022, Mark Brown <broonie@kernel.org> wrote:

> > I would expect them to work, they seemed happy when I was doing
> > the async mode support IIRC and a quick spin with -next in qemu
> > everything seems fine, I'm travelling so don't have the
> > environment for models to hand right now.

> Thanks; I think that points to some setup/config problem on my side,
> then :/ (I ran the selftests under QEMU's tcg emulation, and while it
> looks better, I still get timeouts for check_gcr_el1_cswitch and
> check_user_mem.)

That might just be an actual timeout depending on the preformance of
the host system.

> >> where $AXF contains a kernel at v5.18-rc5-16-g107c948d1d3e[2] and an
> >> initrd built by mbuto[3] from that level with a slightly tweaked "kselftests"
> >> profile (adding /dev/shm).

> > What are you using for EL3 with the model?  Both TF-A and
> > boot-wrapper are in regular use, TF-A gets *way* more testing
> > than boot-wrapper which is mostly used by individual developers.

> I'm building the .axf via boot-wrapper-aarch64 (enabling psci and gicv3,
> if that matters.) Didn't try to make use of TF-A yet beyond the dtb (I'm
> still in the process of getting familiar with the arm64 world, so I'm
> currently starting out with the setups that others had shared with me.)

I'm now back with the models and it turns out that while qemu is happy I
can reproduce what you're seeing with the model, at least as far back as
v5.15 which suggests it's likely to be more operator error than a bug.
Trying to figure it out now.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: [ARM64] status of MTE selftests?

[Mark Brown]

[-- Attachment #1.1: Type: text/plain, Size: 1617 bytes --]

On Mon, May 09, 2022 at 11:59:59AM +0200, Cornelia Huck wrote:
> On Fri, May 06 2022, Mark Brown <broonie@kernel.org> wrote:

> > I would expect them to work, they seemed happy when I was doing
> > the async mode support IIRC and a quick spin with -next in qemu
> > everything seems fine, I'm travelling so don't have the
> > environment for models to hand right now.

> Thanks; I think that points to some setup/config problem on my side,
> then :/ (I ran the selftests under QEMU's tcg emulation, and while it
> looks better, I still get timeouts for check_gcr_el1_cswitch and
> check_user_mem.)

That might just be an actual timeout depending on the preformance of
the host system.

> >> where $AXF contains a kernel at v5.18-rc5-16-g107c948d1d3e[2] and an
> >> initrd built by mbuto[3] from that level with a slightly tweaked "kselftests"
> >> profile (adding /dev/shm).

> > What are you using for EL3 with the model?  Both TF-A and
> > boot-wrapper are in regular use, TF-A gets *way* more testing
> > than boot-wrapper which is mostly used by individual developers.

> I'm building the .axf via boot-wrapper-aarch64 (enabling psci and gicv3,
> if that matters.) Didn't try to make use of TF-A yet beyond the dtb (I'm
> still in the process of getting familiar with the arm64 world, so I'm
> currently starting out with the setups that others had shared with me.)

I'm now back with the models and it turns out that while qemu is happy I
can reproduce what you're seeing with the model, at least as far back as
v5.15 which suggests it's likely to be more operator error than a bug.
Trying to figure it out now.

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

[-- Attachment #2: Type: text/plain, Size: 176 bytes --]

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [ARM64] status of MTE selftests?

[Cornelia Huck]

On Mon, May 09 2022, Mark Brown <broonie@kernel.org> wrote:

> On Mon, May 09, 2022 at 11:59:59AM +0200, Cornelia Huck wrote:
>> On Fri, May 06 2022, Mark Brown <broonie@kernel.org> wrote:
>
>> > I would expect them to work, they seemed happy when I was doing
>> > the async mode support IIRC and a quick spin with -next in qemu
>> > everything seems fine, I'm travelling so don't have the
>> > environment for models to hand right now.
>
>> Thanks; I think that points to some setup/config problem on my side,
>> then :/ (I ran the selftests under QEMU's tcg emulation, and while it
>> looks better, I still get timeouts for check_gcr_el1_cswitch and
>> check_user_mem.)
>
> That might just be an actual timeout depending on the preformance of
> the host system.

Our mails may have crossed mid-air; the tests finish for me eventually.

>
>> >> where $AXF contains a kernel at v5.18-rc5-16-g107c948d1d3e[2] and an
>> >> initrd built by mbuto[3] from that level with a slightly tweaked "kselftests"
>> >> profile (adding /dev/shm).
>
>> > What are you using for EL3 with the model?  Both TF-A and
>> > boot-wrapper are in regular use, TF-A gets *way* more testing
>> > than boot-wrapper which is mostly used by individual developers.
>
>> I'm building the .axf via boot-wrapper-aarch64 (enabling psci and gicv3,
>> if that matters.) Didn't try to make use of TF-A yet beyond the dtb (I'm
>> still in the process of getting familiar with the arm64 world, so I'm
>> currently starting out with the setups that others had shared with me.)
>
> I'm now back with the models and it turns out that while qemu is happy I
> can reproduce what you're seeing with the model, at least as far back as
> v5.15 which suggests it's likely to be more operator error than a bug.
> Trying to figure it out now.

Ok, thanks for looking.

Re: [ARM64] status of MTE selftests?

[Cornelia Huck]

On Mon, May 09 2022, Mark Brown <broonie@kernel.org> wrote:

> On Mon, May 09, 2022 at 11:59:59AM +0200, Cornelia Huck wrote:
>> On Fri, May 06 2022, Mark Brown <broonie@kernel.org> wrote:
>
>> > I would expect them to work, they seemed happy when I was doing
>> > the async mode support IIRC and a quick spin with -next in qemu
>> > everything seems fine, I'm travelling so don't have the
>> > environment for models to hand right now.
>
>> Thanks; I think that points to some setup/config problem on my side,
>> then :/ (I ran the selftests under QEMU's tcg emulation, and while it
>> looks better, I still get timeouts for check_gcr_el1_cswitch and
>> check_user_mem.)
>
> That might just be an actual timeout depending on the preformance of
> the host system.

Our mails may have crossed mid-air; the tests finish for me eventually.

>
>> >> where $AXF contains a kernel at v5.18-rc5-16-g107c948d1d3e[2] and an
>> >> initrd built by mbuto[3] from that level with a slightly tweaked "kselftests"
>> >> profile (adding /dev/shm).
>
>> > What are you using for EL3 with the model?  Both TF-A and
>> > boot-wrapper are in regular use, TF-A gets *way* more testing
>> > than boot-wrapper which is mostly used by individual developers.
>
>> I'm building the .axf via boot-wrapper-aarch64 (enabling psci and gicv3,
>> if that matters.) Didn't try to make use of TF-A yet beyond the dtb (I'm
>> still in the process of getting familiar with the arm64 world, so I'm
>> currently starting out with the setups that others had shared with me.)
>
> I'm now back with the models and it turns out that while qemu is happy I
> can reproduce what you're seeing with the model, at least as far back as
> v5.15 which suggests it's likely to be more operator error than a bug.
> Trying to figure it out now.

Ok, thanks for looking.


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [ARM64] status of MTE selftests?

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 543 bytes --]

On Fri, May 06, 2022 at 04:50:41PM +0200, Cornelia Huck wrote:

> [1] Command line:
> "$MODEL" \
> -C cache_state_modelled=0 \
> -C bp.refcounter.non_arch_start_at_default=1 \
> -C bp.secure_memory=false \
> -C cluster0.has_arm_v8-1=1 \
> -C cluster0.has_arm_v8-2=1 \
> -C cluster0.has_arm_v8-3=1 \
> -C cluster0.has_arm_v8-4=1 \
> -C cluster0.has_arm_v8-5=1 \
> -C cluster0.has_amu=1 \
> -C cluster0.NUM_CORES=4 \
> -C cluster0.memory_tagging_support_level=2 \
> -a "cluster0.*=$AXF" \

You need to set bp.dram_metadata.is_enabled=1 as well.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: [ARM64] status of MTE selftests?

[Mark Brown]

[-- Attachment #1.1: Type: text/plain, Size: 543 bytes --]

On Fri, May 06, 2022 at 04:50:41PM +0200, Cornelia Huck wrote:

> [1] Command line:
> "$MODEL" \
> -C cache_state_modelled=0 \
> -C bp.refcounter.non_arch_start_at_default=1 \
> -C bp.secure_memory=false \
> -C cluster0.has_arm_v8-1=1 \
> -C cluster0.has_arm_v8-2=1 \
> -C cluster0.has_arm_v8-3=1 \
> -C cluster0.has_arm_v8-4=1 \
> -C cluster0.has_arm_v8-5=1 \
> -C cluster0.has_amu=1 \
> -C cluster0.NUM_CORES=4 \
> -C cluster0.memory_tagging_support_level=2 \
> -a "cluster0.*=$AXF" \

You need to set bp.dram_metadata.is_enabled=1 as well.

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

[-- Attachment #2: Type: text/plain, Size: 176 bytes --]

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [ARM64] status of MTE selftests?

[Cornelia Huck]

On Wed, May 11 2022, Mark Brown <broonie@kernel.org> wrote:

> On Fri, May 06, 2022 at 04:50:41PM +0200, Cornelia Huck wrote:
>
>> [1] Command line:
>> "$MODEL" \
>> -C cache_state_modelled=0 \
>> -C bp.refcounter.non_arch_start_at_default=1 \
>> -C bp.secure_memory=false \
>> -C cluster0.has_arm_v8-1=1 \
>> -C cluster0.has_arm_v8-2=1 \
>> -C cluster0.has_arm_v8-3=1 \
>> -C cluster0.has_arm_v8-4=1 \
>> -C cluster0.has_arm_v8-5=1 \
>> -C cluster0.has_amu=1 \
>> -C cluster0.NUM_CORES=4 \
>> -C cluster0.memory_tagging_support_level=2 \
>> -a "cluster0.*=$AXF" \
>
> You need to set bp.dram_metadata.is_enabled=1 as well.

Aha! Indeed, with that set it all works. (Too bad that the config
doesn't moan when it's not set...)

Thanks a lot!

Re: [ARM64] status of MTE selftests?

[Cornelia Huck]

On Wed, May 11 2022, Mark Brown <broonie@kernel.org> wrote:

> On Fri, May 06, 2022 at 04:50:41PM +0200, Cornelia Huck wrote:
>
>> [1] Command line:
>> "$MODEL" \
>> -C cache_state_modelled=0 \
>> -C bp.refcounter.non_arch_start_at_default=1 \
>> -C bp.secure_memory=false \
>> -C cluster0.has_arm_v8-1=1 \
>> -C cluster0.has_arm_v8-2=1 \
>> -C cluster0.has_arm_v8-3=1 \
>> -C cluster0.has_arm_v8-4=1 \
>> -C cluster0.has_arm_v8-5=1 \
>> -C cluster0.has_amu=1 \
>> -C cluster0.NUM_CORES=4 \
>> -C cluster0.memory_tagging_support_level=2 \
>> -a "cluster0.*=$AXF" \
>
> You need to set bp.dram_metadata.is_enabled=1 as well.

Aha! Indeed, with that set it all works. (Too bad that the config
doesn't moan when it's not set...)

Thanks a lot!


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel