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


_______________________________________________
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.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.)


_______________________________________________
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.


_______________________________________________
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.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.


_______________________________________________
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.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!


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