* Re: [ARM64] status of MTE selftests? [not found] <87wney4svy.fsf@redhat.com> @ 2022-05-06 15:09 ` Cornelia Huck 2022-05-06 16:32 ` Mark Brown 2022-05-11 12:48 ` Mark Brown 2 siblings, 0 replies; 8+ messages in thread From: Cornelia Huck @ 2022-05-06 15:09 UTC (permalink / raw) To: Catalin Marinas, Will Deacon, Shuah Khan, Mark Brown, Joey Gouly Cc: linux-arm-kernel, linux-kselftest [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 ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [ARM64] status of MTE selftests? [not found] <87wney4svy.fsf@redhat.com> 2022-05-06 15:09 ` [ARM64] status of MTE selftests? Cornelia Huck @ 2022-05-06 16:32 ` Mark Brown 2022-05-09 9:59 ` Cornelia Huck 2022-05-11 12:48 ` Mark Brown 2 siblings, 1 reply; 8+ messages in thread From: Mark Brown @ 2022-05-06 16:32 UTC (permalink / raw) To: Cornelia Huck Cc: Catalin Marinas, Will Deacon, Shuah Khan, Joey Gouly, linux-arm-kernel, linux-kselftest [-- 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 ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [ARM64] status of MTE selftests? 2022-05-06 16:32 ` Mark Brown @ 2022-05-09 9:59 ` Cornelia Huck 2022-05-09 14:59 ` Cornelia Huck 2022-05-09 15:18 ` Mark Brown 0 siblings, 2 replies; 8+ messages in thread From: Cornelia Huck @ 2022-05-09 9:59 UTC (permalink / raw) To: Mark Brown Cc: Catalin Marinas, Will Deacon, Shuah Khan, Joey Gouly, linux-arm-kernel, linux-kselftest 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 ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [ARM64] status of MTE selftests? 2022-05-09 9:59 ` Cornelia Huck @ 2022-05-09 14:59 ` Cornelia Huck 2022-05-09 15:18 ` Mark Brown 1 sibling, 0 replies; 8+ messages in thread From: Cornelia Huck @ 2022-05-09 14:59 UTC (permalink / raw) To: Mark Brown Cc: Catalin Marinas, Will Deacon, Shuah Khan, Joey Gouly, linux-arm-kernel, linux-kselftest 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 ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [ARM64] status of MTE selftests? 2022-05-09 9:59 ` Cornelia Huck 2022-05-09 14:59 ` Cornelia Huck @ 2022-05-09 15:18 ` Mark Brown 2022-05-09 15:40 ` Cornelia Huck 1 sibling, 1 reply; 8+ messages in thread From: Mark Brown @ 2022-05-09 15:18 UTC (permalink / raw) To: Cornelia Huck Cc: Catalin Marinas, Will Deacon, Shuah Khan, Joey Gouly, linux-arm-kernel, linux-kselftest [-- 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 ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [ARM64] status of MTE selftests? 2022-05-09 15:18 ` Mark Brown @ 2022-05-09 15:40 ` Cornelia Huck 0 siblings, 0 replies; 8+ messages in thread From: Cornelia Huck @ 2022-05-09 15:40 UTC (permalink / raw) To: Mark Brown Cc: Catalin Marinas, Will Deacon, Shuah Khan, Joey Gouly, linux-arm-kernel, linux-kselftest 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 ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [ARM64] status of MTE selftests? [not found] <87wney4svy.fsf@redhat.com> 2022-05-06 15:09 ` [ARM64] status of MTE selftests? Cornelia Huck 2022-05-06 16:32 ` Mark Brown @ 2022-05-11 12:48 ` Mark Brown 2022-05-11 13:15 ` Cornelia Huck 2 siblings, 1 reply; 8+ messages in thread From: Mark Brown @ 2022-05-11 12:48 UTC (permalink / raw) To: Cornelia Huck Cc: Catalin Marinas, Will Deacon, Shuah Khan, Joey Gouly, linux-arm-kernel, linux-kselftest [-- 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 ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [ARM64] status of MTE selftests? 2022-05-11 12:48 ` Mark Brown @ 2022-05-11 13:15 ` Cornelia Huck 0 siblings, 0 replies; 8+ messages in thread From: Cornelia Huck @ 2022-05-11 13:15 UTC (permalink / raw) To: Mark Brown Cc: Catalin Marinas, Will Deacon, Shuah Khan, Joey Gouly, linux-arm-kernel, linux-kselftest 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 ^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2022-05-11 13:17 UTC | newest]
Thread overview: 8+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
[not found] <87wney4svy.fsf@redhat.com>
2022-05-06 15:09 ` [ARM64] status of MTE selftests? Cornelia Huck
2022-05-06 16:32 ` Mark Brown
2022-05-09 9:59 ` Cornelia Huck
2022-05-09 14:59 ` Cornelia Huck
2022-05-09 15:18 ` Mark Brown
2022-05-09 15:40 ` Cornelia Huck
2022-05-11 12:48 ` Mark Brown
2022-05-11 13:15 ` Cornelia Huck
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).