From: Nick Desaulniers <ndesaulniers@google.com> To: Ard Biesheuvel <ardb@kernel.org> Cc: linux-efi <linux-efi@vger.kernel.org>, Linux ARM <linux-arm-kernel@lists.infradead.org>, Russell King <linux@armlinux.org.uk>, Linus Walleij <linus.walleij@linaro.org>, Nicolas Pitre <nico@fluxnic.net>, Stefan Agner <stefan@agner.ch>, Peter Smith <Peter.Smith@arm.com>, Marc Zyngier <maz@kernel.org>, Will Deacon <will@kernel.org>, clang-built-linux <clang-built-linux@googlegroups.com>, Jian Cai <jiancai@google.com>, Nathan Chancellor <natechancellor@gmail.com>, Masahiro Yamada <masahiroy@kernel.org> Subject: Re: [PATCH 00/12] ARM: use adr_l/ldr_l macros for PC-relative references Date: Fri, 18 Sep 2020 13:03:02 -0700 [thread overview] Message-ID: <CAKwvOd=8QUQK6hCQaAGjX6o_jz_vgFewW6v+SPHZ7ZKi9LYcYw@mail.gmail.com> (raw) In-Reply-To: <CAMj1kXG9WBZb9WYCCng7CkJ+v8X=xHVhih274iuXMd5ua2nKPg@mail.gmail.com> On Wed, Sep 16, 2020 at 11:01 PM Ard Biesheuvel <ardb@kernel.org> wrote: > > On Thu, 17 Sep 2020 at 00:25, Nick Desaulniers <ndesaulniers@google.com> wrote: > > Also, it looks like the GCC build of milbeaut_m10v_defconfig fails to > > boot for me in QEMU; so maybe not just a Clang bug (or maybe, more > > than one bug). (or maybe one of my command line params to QEMU is > > wrong). > > > > I understand that this is actually an existing issue in -next, but in > general, why would you expect to be able to boot > milbeaut_m10v_defconfig on anything other than a Milbeaut MV10 > machine? We've been booting other configs in QEMU for a few years now, so I don't see why yet another config would hurt. Maybe there's some hardware dependency, but I guess we'd find that out trying to boot it in QEMU. If it boots in QEMU, I guess not booting on metal wasn't so bad? Maybe this is considered an antipattern, but you can see how if we've been getting away with it for years then that would lead to such expectations. > (whatever it is) Or does QEMU emulate a milbeaut machine? $ qemu-system-arm -machine help doesn't print anything that looks like it, on initial glance. Looks like a socionext part: https://www.socionext.com/en/pr/sn_pr20170105_01e.pdf > If > not, better to stick with configs that are intended to boot on the > QEMU machine emulation that you are using. I can see in our CI that we've been building+boot testing multi_v5_defconfig, aspeed_g5_defconfig, and multi_v7_defconfig for a while now without specifying any machine. Is there a preferred machine we should be using for those? (It looks like qemu supports ast2500-evb and ast2600-evb; is ARM1176 and ARMv6 core? Is that what aspeed_g5 uses? Why is virt versioned? Ahhhh!!!!) > Also, while I see the point of regression testing of -next, using it > as a base to test arbitrary series and then report failures against it > produces a lot of noise. -next is *not* a good base for development, > because you get everybody else's half baked crap as well. Ack. > When you > test my stuff, please use a known good base so we're not off on a > goose chase every time. Goose Chase?! gOoSe ChAsE?! *gestures broadly at...everything* Monsieur, here at the zoo, chasing the geese is not out of our purview. It's preferable to cleaning up after the elephants. -- Thanks, ~Nick Desaulniers
WARNING: multiple messages have this Message-ID (diff)
From: Nick Desaulniers <ndesaulniers@google.com> To: Ard Biesheuvel <ardb@kernel.org> Cc: linux-efi <linux-efi@vger.kernel.org>, Nicolas Pitre <nico@fluxnic.net>, Marc Zyngier <maz@kernel.org>, Linus Walleij <linus.walleij@linaro.org>, Russell King <linux@armlinux.org.uk>, Stefan Agner <stefan@agner.ch>, Peter Smith <Peter.Smith@arm.com>, clang-built-linux <clang-built-linux@googlegroups.com>, Nathan Chancellor <natechancellor@gmail.com>, Jian Cai <jiancai@google.com>, Will Deacon <will@kernel.org>, Masahiro Yamada <masahiroy@kernel.org>, Linux ARM <linux-arm-kernel@lists.infradead.org> Subject: Re: [PATCH 00/12] ARM: use adr_l/ldr_l macros for PC-relative references Date: Fri, 18 Sep 2020 13:03:02 -0700 [thread overview] Message-ID: <CAKwvOd=8QUQK6hCQaAGjX6o_jz_vgFewW6v+SPHZ7ZKi9LYcYw@mail.gmail.com> (raw) In-Reply-To: <CAMj1kXG9WBZb9WYCCng7CkJ+v8X=xHVhih274iuXMd5ua2nKPg@mail.gmail.com> On Wed, Sep 16, 2020 at 11:01 PM Ard Biesheuvel <ardb@kernel.org> wrote: > > On Thu, 17 Sep 2020 at 00:25, Nick Desaulniers <ndesaulniers@google.com> wrote: > > Also, it looks like the GCC build of milbeaut_m10v_defconfig fails to > > boot for me in QEMU; so maybe not just a Clang bug (or maybe, more > > than one bug). (or maybe one of my command line params to QEMU is > > wrong). > > > > I understand that this is actually an existing issue in -next, but in > general, why would you expect to be able to boot > milbeaut_m10v_defconfig on anything other than a Milbeaut MV10 > machine? We've been booting other configs in QEMU for a few years now, so I don't see why yet another config would hurt. Maybe there's some hardware dependency, but I guess we'd find that out trying to boot it in QEMU. If it boots in QEMU, I guess not booting on metal wasn't so bad? Maybe this is considered an antipattern, but you can see how if we've been getting away with it for years then that would lead to such expectations. > (whatever it is) Or does QEMU emulate a milbeaut machine? $ qemu-system-arm -machine help doesn't print anything that looks like it, on initial glance. Looks like a socionext part: https://www.socionext.com/en/pr/sn_pr20170105_01e.pdf > If > not, better to stick with configs that are intended to boot on the > QEMU machine emulation that you are using. I can see in our CI that we've been building+boot testing multi_v5_defconfig, aspeed_g5_defconfig, and multi_v7_defconfig for a while now without specifying any machine. Is there a preferred machine we should be using for those? (It looks like qemu supports ast2500-evb and ast2600-evb; is ARM1176 and ARMv6 core? Is that what aspeed_g5 uses? Why is virt versioned? Ahhhh!!!!) > Also, while I see the point of regression testing of -next, using it > as a base to test arbitrary series and then report failures against it > produces a lot of noise. -next is *not* a good base for development, > because you get everybody else's half baked crap as well. Ack. > When you > test my stuff, please use a known good base so we're not off on a > goose chase every time. Goose Chase?! gOoSe ChAsE?! *gestures broadly at...everything* Monsieur, here at the zoo, chasing the geese is not out of our purview. It's preferable to cleaning up after the elephants. -- Thanks, ~Nick Desaulniers _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2020-09-18 20:03 UTC|newest] Thread overview: 62+ messages / expand[flat|nested] mbox.gz Atom feed top 2020-09-14 9:56 [PATCH 00/12] ARM: use adr_l/ldr_l macros for PC-relative references Ard Biesheuvel 2020-09-14 9:56 ` Ard Biesheuvel 2020-09-14 9:56 ` [PATCH 01/12] ARM: assembler: introduce adr_l, ldr_l and str_l macros Ard Biesheuvel 2020-09-14 9:56 ` Ard Biesheuvel 2020-09-15 7:35 ` Ard Biesheuvel 2020-09-15 7:35 ` Ard Biesheuvel 2020-09-15 17:51 ` Nick Desaulniers 2020-09-15 17:51 ` Nick Desaulniers 2020-09-14 9:56 ` [PATCH 02/12] ARM: efistub: replace adrl pseudo-op with adr_l macro invocation Ard Biesheuvel 2020-09-14 9:56 ` Ard Biesheuvel 2020-09-14 9:56 ` [PATCH 03/12] ARM: module: add support for place relative relocations Ard Biesheuvel 2020-09-14 9:56 ` Ard Biesheuvel 2020-09-14 13:35 ` Nicolas Pitre 2020-09-14 13:35 ` Nicolas Pitre 2020-09-14 16:11 ` Russell King - ARM Linux admin 2020-09-14 16:11 ` Russell King - ARM Linux admin 2020-09-14 9:56 ` [PATCH 04/12] ARM: head-common.S: use PC-relative insn sequence for __proc_info Ard Biesheuvel 2020-09-14 9:56 ` Ard Biesheuvel 2020-09-14 9:56 ` [PATCH 05/12] ARM: head-common.S: use PC-relative insn sequence for idmap creation Ard Biesheuvel 2020-09-14 9:56 ` Ard Biesheuvel 2020-09-14 9:57 ` [PATCH 06/12] ARM: head.S: use PC-relative insn sequence for secondary_data Ard Biesheuvel 2020-09-14 9:57 ` Ard Biesheuvel 2020-09-14 9:57 ` [PATCH 07/12] ARM: kernel: use relative references for UP/SMP alternatives Ard Biesheuvel 2020-09-14 9:57 ` Ard Biesheuvel 2020-09-14 9:57 ` [PATCH 08/12] ARM: head: use PC-relative insn sequence for __smp_alt Ard Biesheuvel 2020-09-14 9:57 ` Ard Biesheuvel 2020-09-14 9:57 ` [PATCH 09/12] ARM: sleep.S: use PC-relative insn sequence for sleep_save_sp/mpidr_hash Ard Biesheuvel 2020-09-14 9:57 ` Ard Biesheuvel 2020-09-14 9:57 ` [PATCH 10/12] ARM: head.S: use PC-relative insn sequences for __fixup_pv_table Ard Biesheuvel 2020-09-14 9:57 ` Ard Biesheuvel 2020-09-14 9:57 ` [PATCH 11/12] ARM: head.S: use PC relative insn sequence to calculate PHYS_OFFSET Ard Biesheuvel 2020-09-14 9:57 ` Ard Biesheuvel 2020-09-14 9:57 ` [PATCH 12/12] ARM: kvm: replace open coded VA->PA calculations with adr_l call Ard Biesheuvel 2020-09-14 9:57 ` Ard Biesheuvel 2020-09-14 14:06 ` [PATCH 00/12] ARM: use adr_l/ldr_l macros for PC-relative references Nicolas Pitre 2020-09-14 14:06 ` Nicolas Pitre 2020-09-15 19:32 ` Nick Desaulniers 2020-09-15 19:32 ` Nick Desaulniers 2020-09-15 21:29 ` Ard Biesheuvel 2020-09-15 21:29 ` Ard Biesheuvel 2020-09-15 23:31 ` Nick Desaulniers 2020-09-15 23:31 ` Nick Desaulniers 2020-09-16 5:54 ` Ard Biesheuvel 2020-09-16 5:54 ` Ard Biesheuvel 2020-09-16 19:53 ` Nick Desaulniers 2020-09-16 19:53 ` Nick Desaulniers 2020-09-16 20:45 ` Ard Biesheuvel 2020-09-16 20:45 ` Ard Biesheuvel 2020-09-16 21:25 ` Nick Desaulniers 2020-09-16 21:25 ` Nick Desaulniers 2020-09-17 0:16 ` Nick Desaulniers 2020-09-17 0:16 ` Nick Desaulniers 2020-09-17 5:19 ` Mike Rapoport 2020-09-17 5:19 ` Mike Rapoport 2020-09-17 6:01 ` Ard Biesheuvel 2020-09-17 6:01 ` Ard Biesheuvel 2020-09-18 20:03 ` Nick Desaulniers [this message] 2020-09-18 20:03 ` Nick Desaulniers 2020-09-18 20:44 ` Ard Biesheuvel 2020-09-18 20:44 ` Ard Biesheuvel 2020-09-18 21:06 ` Nick Desaulniers 2020-09-18 21:06 ` Nick Desaulniers
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='CAKwvOd=8QUQK6hCQaAGjX6o_jz_vgFewW6v+SPHZ7ZKi9LYcYw@mail.gmail.com' \ --to=ndesaulniers@google.com \ --cc=Peter.Smith@arm.com \ --cc=ardb@kernel.org \ --cc=clang-built-linux@googlegroups.com \ --cc=jiancai@google.com \ --cc=linus.walleij@linaro.org \ --cc=linux-arm-kernel@lists.infradead.org \ --cc=linux-efi@vger.kernel.org \ --cc=linux@armlinux.org.uk \ --cc=masahiroy@kernel.org \ --cc=maz@kernel.org \ --cc=natechancellor@gmail.com \ --cc=nico@fluxnic.net \ --cc=stefan@agner.ch \ --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.