From: Cornelia Huck <cohuck@redhat.com> To: Mark Brown <broonie@kernel.org> Cc: Catalin Marinas <catalin.marinas@arm.com>, Will Deacon <will@kernel.org>, Shuah Khan <shuah@kernel.org>, Joey Gouly <joey.gouly@arm.com>, linux-arm-kernel@lists.infradead.org, linux-kselftest@vger.kernel.org Subject: Re: [ARM64] status of MTE selftests? Date: Mon, 09 May 2022 11:59:59 +0200 [thread overview] Message-ID: <87levb3u1s.fsf@redhat.com> (raw) In-Reply-To: <YnVNADyaft0WkNHu@sirena.org.uk> 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
WARNING: multiple messages have this Message-ID (diff)
From: Cornelia Huck <cohuck@redhat.com> To: Mark Brown <broonie@kernel.org> Cc: Catalin Marinas <catalin.marinas@arm.com>, Will Deacon <will@kernel.org>, Shuah Khan <shuah@kernel.org>, Joey Gouly <joey.gouly@arm.com>, linux-arm-kernel@lists.infradead.org, linux-kselftest@vger.kernel.org Subject: Re: [ARM64] status of MTE selftests? Date: Mon, 09 May 2022 11:59:59 +0200 [thread overview] Message-ID: <87levb3u1s.fsf@redhat.com> (raw) In-Reply-To: <YnVNADyaft0WkNHu@sirena.org.uk> 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.)
next prev parent reply other threads:[~2022-05-09 10:01 UTC|newest] Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top [not found] <87wney4svy.fsf@redhat.com> 2022-05-06 15:09 ` [ARM64] status of MTE selftests? Cornelia Huck 2022-05-06 15:09 ` Cornelia Huck 2022-05-06 16:32 ` Mark Brown 2022-05-06 16:32 ` Mark Brown 2022-05-09 9:59 ` Cornelia Huck [this message] 2022-05-09 9:59 ` Cornelia Huck 2022-05-09 14:59 ` Cornelia Huck 2022-05-09 14:59 ` Cornelia Huck 2022-05-09 15:18 ` Mark Brown 2022-05-09 15:18 ` Mark Brown 2022-05-09 15:40 ` Cornelia Huck 2022-05-09 15:40 ` Cornelia Huck 2022-05-11 12:48 ` Mark Brown 2022-05-11 12:48 ` Mark Brown 2022-05-11 13:15 ` Cornelia Huck 2022-05-11 13:15 ` Cornelia Huck
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=87levb3u1s.fsf@redhat.com \ --to=cohuck@redhat.com \ --cc=broonie@kernel.org \ --cc=catalin.marinas@arm.com \ --cc=joey.gouly@arm.com \ --cc=linux-arm-kernel@lists.infradead.org \ --cc=linux-kselftest@vger.kernel.org \ --cc=shuah@kernel.org \ --cc=will@kernel.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: linkBe 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.