From thuth at redhat.com Fri Jul 1 03:02:48 2022 From: thuth at redhat.com (Thomas Huth) Date: Thu, 30 Jun 2022 19:02:48 +0200 Subject: [SLOF] [PATCH] lib/libnet/ipv6: Silence compiler warning from Clang In-Reply-To: <20220628151927.GD25951@gate.crashing.org> References: <20220627082632.25192-1-thuth@redhat.com> <20220627220531.GC25951@gate.crashing.org> <20220628151927.GD25951@gate.crashing.org> Message-ID: <62c0a882-a68b-ccea-d5db-3a551119c4d8@redhat.com> On 28/06/2022 17.19, Segher Boessenkool wrote: > Hi! > > On Tue, Jun 28, 2022 at 06:40:23PM +1000, Alexey Kardashevskiy wrote: >> On 6/28/22 16:34, Thomas Huth wrote: >>> On 28/06/2022 00.05, Segher Boessenkool wrote: >>>> On Mon, Jun 27, 2022 at 10:26:32AM +0200, Thomas Huth wrote: >>>>> When compiling the libnet code with Clang (e.g. for the s390-ccw bios), >>>>> it complains with the following warning: >>>>> >>>>> ? ipv6.c:447:18: warning: variable length array folded to constant array >>>>> ?? as an extension [-Wgnu-folding-constant] >>>>> ???????????????? unsigned short raw[ip6size]; >>>>> ??????????????????????????????? ^ >>>>> The warning is completely harmless, of course. Anyway let's rewrite the >>>>> code a little bit to make the compiler silent again. >>>> >>>> This makes the code worse though :-( >>>> >>>> You could shut off the silly warning instead?? Clang claims to be >>>> compatible to GCC, and GCC explicitly allows variable-length auto >>>> arrays even in C90 mode.? This is documented, too. >>> >>> Ok, can do, SLOF itself cannot be compiled with Clang anyway, so it >>> likely makes more sense indeed to disable this warning in the s390-ccw >>> bios that uses SLOF's libnet. >> >> I rather like the initial idea of getting rid of ip6size, I tend to >> (incorrectly) read "ip6size" as "size of the ipv6 header in bytes" (as >> sizes are almost always bytes) which it is not here. > > It could use a better name no matter what, it doesn't even say "header" :-) > > Using ARRAY_SIZE this will probably look a lot better, with or without > the change? FYI, I'm going with this patch for the s390-ccw bios: https://lists.gnu.org/archive/html/qemu-devel/2022-06/msg05306.html I think that's the right way to go since SLOF cannot be compiled with Clang yet. Thomas From segher at kernel.crashing.org Fri Jul 1 03:17:49 2022 From: segher at kernel.crashing.org (Segher Boessenkool) Date: Thu, 30 Jun 2022 12:17:49 -0500 Subject: [SLOF] [PATCH] lib/libnet/ipv6: Silence compiler warning from Clang In-Reply-To: <62c0a882-a68b-ccea-d5db-3a551119c4d8@redhat.com> References: <20220627082632.25192-1-thuth@redhat.com> <20220627220531.GC25951@gate.crashing.org> <20220628151927.GD25951@gate.crashing.org> <62c0a882-a68b-ccea-d5db-3a551119c4d8@redhat.com> Message-ID: <20220630171749.GL25951@gate.crashing.org> On Thu, Jun 30, 2022 at 07:02:48PM +0200, Thomas Huth wrote: > FYI, I'm going with this patch for the s390-ccw bios: > > https://lists.gnu.org/archive/html/qemu-devel/2022-06/msg05306.html > > I think that's the right way to go since SLOF cannot be compiled with Clang > yet. Looks good! +1 Segher From jniethe5 at gmail.com Tue Jul 12 10:46:24 2022 From: jniethe5 at gmail.com (Jordan Niethe) Date: Tue, 12 Jul 2022 10:46:24 +1000 Subject: [SLOF] [PATCH] OF: Add a separate direct kernel loading word Message-ID: <20220712004624.284935-1-jniethe5@gmail.com> Currently, go-64 is used for booting a kernel from qemu (i.e. -kernel). However, there is an expectation from users that this should be able to boot not just vmlinux kernels but things like Zimages too. The bootwrapper of a BE zImage is a 32-bit ELF. Attempting to load that with go-64 means that it will be ran with MSR_SF set (64-bit mode). This crashes early in boot (usually due to what should be 32-bit operations being done with 64-bit registers eventually leading to an incorrect address being generated and branched to). Note that our 64-bit payloads are prepared to enter with MSR_SF cleared and set it themselves very early. Add a new word named go-direct that will execute any simple payload in-place and will enter with MSR_SF cleared. This allows booting a BE zImage from qemu with -machine kernel-addr=0. Signed-off-by: Jordan Niethe --- board-qemu/slof/OF.fs | 5 ++--- slof/fs/boot.fs | 6 ++++++ 2 files changed, 8 insertions(+), 3 deletions(-) diff --git a/board-qemu/slof/OF.fs b/board-qemu/slof/OF.fs index f0fc9c684b8e..3bcb2af94bdd 100644 --- a/board-qemu/slof/OF.fs +++ b/board-qemu/slof/OF.fs @@ -303,10 +303,9 @@ set-default-console : (boot-ram) direct-ram-boot-size 0<> IF ." Booting from memory..." cr - s" go-args 2@ " evaluate - direct-ram-boot-base 0 + s" direct-ram-boot-base to go-entry" evaluate s" true state-valid ! " evaluate - s" disable-watchdog go-64" evaluate + s" disable-watchdog go-direct" evaluate THEN ; diff --git a/slof/fs/boot.fs b/slof/fs/boot.fs index 6d16c54d2af4..a6dfdf3f6c1c 100644 --- a/slof/fs/boot.fs +++ b/slof/fs/boot.fs @@ -112,6 +112,12 @@ defer go ( -- ) claim-list elf-release 0 to claim-list ; +: go-direct ( -- ) + 0 ciregs >r3 ! 0 ciregs >r4 ! 0 ciregs >r2 ! + msr@ 7fffffffffffffff and 2000 or ciregs >srr1 ! + go-args 2@ go-entry call-client +; + : set-le ( -- ) 1 ciregs >r13 ! ; -- 2.25.1 From segher at kernel.crashing.org Tue Jul 12 23:48:19 2022 From: segher at kernel.crashing.org (Segher Boessenkool) Date: Tue, 12 Jul 2022 08:48:19 -0500 Subject: [SLOF] [PATCH] OF: Add a separate direct kernel loading word In-Reply-To: <20220712004624.284935-1-jniethe5@gmail.com> References: <20220712004624.284935-1-jniethe5@gmail.com> Message-ID: <20220712134819.GL25951@gate.crashing.org> Hi! On Tue, Jul 12, 2022 at 10:46:24AM +1000, Jordan Niethe wrote: > Currently, go-64 is used for booting a kernel from qemu (i.e. -kernel). > However, there is an expectation from users that this should be able to > boot not just vmlinux kernels but things like Zimages too. > > The bootwrapper of a BE zImage is a 32-bit ELF. Attempting to load that > with go-64 means that it will be ran with MSR_SF set (64-bit mode). This > crashes early in boot (usually due to what should be 32-bit operations > being done with 64-bit registers eventually leading to an incorrect > address being generated and branched to). In PowerPC, all operations are done the same in SF=0 and SF=1 modes, except: - For addressing storage, the high 32 bits are ignored if SF=0; - For bdz and bdnz (bc with BO[2]=1) the high 32 bits are ignored; - For integer record form instructions ("dot instructions"), the high 32 bits are ignored. Everything else is done exactly the same with SF=0 -- the high 32 bits of everything are set in exactly the same way, for example. In practice, what bites you is the first item, when doing table jumps: it ends up jumping to 0xffffffff12345678 instead of 0x0000000012345678 when running 32-bit code with SF=1. You get about two million instructions into yaboot before it blows up, for example :-) Dot insns are very common, but you do end up with the result properly (sign-) extended most of the time :-) > Note that our 64-bit payloads are prepared to enter with MSR_SF cleared > and set it themselves very early. > > Add a new word named go-direct that will execute any simple payload > in-place and will enter with MSR_SF cleared. This allows booting a BE > zImage from qemu with -machine kernel-addr=0. Ouch. So you run 64-bit programs in 32-bit mode as well, just hoping they will deal with it? Not a good idea :-( Current Linux is fine with it, but are other payloads, including future Linux? "init-program" is supposed to set the MSR state correctly (in ciregs >srr1), based on the ELF headers (and btw the same is true for the LE flag etc). A little ELF parsing is needed. Hope this helps, Segher From jniethe5 at gmail.com Wed Jul 13 13:38:03 2022 From: jniethe5 at gmail.com (Jordan Niethe) Date: Wed, 13 Jul 2022 13:38:03 +1000 Subject: [SLOF] [PATCH] OF: Add a separate direct kernel loading word In-Reply-To: <20220712134819.GL25951@gate.crashing.org> References: <20220712004624.284935-1-jniethe5@gmail.com> <20220712134819.GL25951@gate.crashing.org> Message-ID: On Tue, Jul 12, 2022 at 11:49 PM Segher Boessenkool wrote: > > Hi! > > On Tue, Jul 12, 2022 at 10:46:24AM +1000, Jordan Niethe wrote: > > Currently, go-64 is used for booting a kernel from qemu (i.e. -kernel). > > However, there is an expectation from users that this should be able to > > boot not just vmlinux kernels but things like Zimages too. > > > > The bootwrapper of a BE zImage is a 32-bit ELF. Attempting to load that > > with go-64 means that it will be ran with MSR_SF set (64-bit mode). This > > crashes early in boot (usually due to what should be 32-bit operations > > being done with 64-bit registers eventually leading to an incorrect > > address being generated and branched to). > > In PowerPC, all operations are done the same in SF=0 and SF=1 modes, > except: > - For addressing storage, the high 32 bits are ignored if SF=0; > - For bdz and bdnz (bc with BO[2]=1) the high 32 bits are ignored; > - For integer record form instructions ("dot instructions"), the high > 32 bits are ignored. > Everything else is done exactly the same with SF=0 -- the high 32 bits > of everything are set in exactly the same way, for example. > > In practice, what bites you is the first item, when doing table jumps: > it ends up jumping to 0xffffffff12345678 instead of 0x0000000012345678 > when running 32-bit code with SF=1. You get about two million > instructions into yaboot before it blows up, for example :-) Dot insns > are very common, but you do end up with the result properly (sign-) > extended most of the time :-) Ah ok, it is the first case happening. For example, here the crash comes after going to $0000000104002f24 when it should be going to $0000000004002f24. Like this: => 0x4002cd8: add r7,r7,r5 2: /x $r7 = 0xffff566c 3: /x $r5 = 0x400d8b8 (gdb) stepi 1: x/i $pc => 0x4002cdc: mtctr r7 2: /x $r7 = 0x104002f24 3: /x $r5 = 0x400d8b8 (gdb) stepi 1: x/i $pc => 0x4002ce0: bctr 2: /x $r7 = 0x104002f24 3: /x $r5 = 0x400d8b8 > > > Note that our 64-bit payloads are prepared to enter with MSR_SF cleared > > and set it themselves very early. > > > > Add a new word named go-direct that will execute any simple payload > > in-place and will enter with MSR_SF cleared. This allows booting a BE > > zImage from qemu with -machine kernel-addr=0. > > Ouch. So you run 64-bit programs in 32-bit mode as well, just hoping > they will deal with it? Not a good idea :-( Current Linux is fine with > it, but are other payloads, including future Linux? In SLOF when using -kernel from qemu it already doesn't do the "Preparing ELF-Format Programs for Execution" things (it runs it in place, always enters the client BE). So I thought these "-kernel" payloads weren't being treated as ELFs but as the kind of client program described in the PowerPC Processor Binding for 1275 (Section 8.2.1 Initial Register Values). That seemed to indicate that a client program will be entered in 32-bit mode. So I thought it might be ok to do... > > "init-program" is supposed to set the MSR state correctly (in ciregs > >srr1), based on the ELF headers (and btw the same is true for the LE > flag etc). A little ELF parsing is needed. When booting from memory with the -kernel option, qemu has already loaded the kernel into memory and tells SLOF where to jump into? SLOF is not looking at the ELF at all in this case is it? Thanks, Jordan > > Hope this helps, > > > Segher From aik at ozlabs.ru Wed Jul 13 14:13:06 2022 From: aik at ozlabs.ru (Alexey Kardashevskiy) Date: Wed, 13 Jul 2022 14:13:06 +1000 Subject: [SLOF] [PATCH] OF: Add a separate direct kernel loading word In-Reply-To: <20220712134819.GL25951@gate.crashing.org> References: <20220712004624.284935-1-jniethe5@gmail.com> <20220712134819.GL25951@gate.crashing.org> Message-ID: <0e83b2b8-7fe5-d2db-44c8-91083eb7961e@ozlabs.ru> On 7/12/22 23:48, Segher Boessenkool wrote: > Hi! > > On Tue, Jul 12, 2022 at 10:46:24AM +1000, Jordan Niethe wrote: >> Currently, go-64 is used for booting a kernel from qemu (i.e. -kernel). >> However, there is an expectation from users that this should be able to >> boot not just vmlinux kernels but things like Zimages too. >> >> The bootwrapper of a BE zImage is a 32-bit ELF. Attempting to load that >> with go-64 means that it will be ran with MSR_SF set (64-bit mode). This >> crashes early in boot (usually due to what should be 32-bit operations >> being done with 64-bit registers eventually leading to an incorrect >> address being generated and branched to). > > In PowerPC, all operations are done the same in SF=0 and SF=1 modes, > except: > - For addressing storage, the high 32 bits are ignored if SF=0; > - For bdz and bdnz (bc with BO[2]=1) the high 32 bits are ignored; > - For integer record form instructions ("dot instructions"), the high > 32 bits are ignored. > Everything else is done exactly the same with SF=0 -- the high 32 bits > of everything are set in exactly the same way, for example. > > In practice, what bites you is the first item, when doing table jumps: > it ends up jumping to 0xffffffff12345678 instead of 0x0000000012345678 > when running 32-bit code with SF=1. You get about two million > instructions into yaboot before it blows up, for example :-) It crashes lot sooner with a BE zImage :) > Dot insns > are very common, but you do end up with the result properly (sign-) > extended most of the time :-) > >> Note that our 64-bit payloads are prepared to enter with MSR_SF cleared >> and set it themselves very early. >> >> Add a new word named go-direct that will execute any simple payload >> in-place and will enter with MSR_SF cleared. This allows booting a BE >> zImage from qemu with -machine kernel-addr=0. > > Ouch. So you run 64-bit programs in 32-bit mode as well, just hoping > they will deal with it? Not a good idea :-( Current Linux is fine with > it, but are other payloads, including future Linux? https://www.devicetree.org/open-firmware/bindings/ppc/release/ppc-2_1.html says "Upon entry to the client program, the following registers shall contain the following values: ... msr ... SF=0, 32-bit mode". I'd think that it is up to that client program to adjust MSR_SF, not the firmware. > "init-program" is supposed to set the MSR state correctly (in ciregs >> srr1), based on the ELF headers (and btw the same is true for the LE > flag etc). A little ELF parsing is needed. This is the case when QEMU runs with "-kernel zImage" - QEMU loads the ELF and SLOF has no idea what was the binary. QEMU does store a "/chosen/qemu,boot-kernel-le" property but there is nothing for 32bit. > > Hope this helps, Always does! :) > > > Segher > _______________________________________________ > SLOF mailing list > SLOF at lists.ozlabs.org > https://lists.ozlabs.org/listinfo/slof -- Alexey From segher at kernel.crashing.org Thu Jul 14 04:11:34 2022 From: segher at kernel.crashing.org (Segher Boessenkool) Date: Wed, 13 Jul 2022 13:11:34 -0500 Subject: [SLOF] [PATCH] OF: Add a separate direct kernel loading word In-Reply-To: <0e83b2b8-7fe5-d2db-44c8-91083eb7961e@ozlabs.ru> References: <20220712004624.284935-1-jniethe5@gmail.com> <20220712134819.GL25951@gate.crashing.org> <0e83b2b8-7fe5-d2db-44c8-91083eb7961e@ozlabs.ru> Message-ID: <20220713181134.GS25951@gate.crashing.org> Hi! On Wed, Jul 13, 2022 at 02:13:06PM +1000, Alexey Kardashevskiy wrote: > On 7/12/22 23:48, Segher Boessenkool wrote: > >Ouch. So you run 64-bit programs in 32-bit mode as well, just hoping > >they will deal with it? Not a good idea :-( Current Linux is fine with > >it, but are other payloads, including future Linux? > > https://www.devicetree.org/open-firmware/bindings/ppc/release/ppc-2_1.html > says "Upon entry to the client program, the following registers shall > contain the following values: ... msr ... SF=0, 32-bit mode". I'd think > that it is up to that client program to adjust MSR_SF, not the firmware. The (later) PowerPC CHRP binding says (in 10.4): The data format of a client program compliant with this specification shall be either ELF (Executable and Linkage Format) as defined by [19], and extended by section 10.4.1.1., or PE (Portable Executable) as defined by [17]. The standard ELF format contains explicit indication as to the program's execution modes (e.g., 32- or 64-bit, Big- or Little-Endian). CHRP only supports the 32-bit version (i.e., ELFCLASS32) for 32 and 64 bit platforms. Note: other client program formats may be supported, in an implementation specific manner, by an Open Firmware implementation. Supporting 64-bit ELF is thus explicitly allowed as well, and various implementations do just that. > >"init-program" is supposed to set the MSR state correctly (in ciregs > >>srr1), based on the ELF headers (and btw the same is true for the LE > >flag etc). A little ELF parsing is needed. > > This is the case when QEMU runs with "-kernel zImage" - QEMU loads the > ELF and SLOF has no idea what was the binary. QEMU does store a > "/chosen/qemu,boot-kernel-le" property but there is nothing for 32bit. Ah, that sucks. Then you'll just have to do what you have to do, no matter how awful it is :-( > >Hope this helps, > > Always does! :) Great to hear that :-) Segher From segher at kernel.crashing.org Thu Jul 14 04:20:02 2022 From: segher at kernel.crashing.org (Segher Boessenkool) Date: Wed, 13 Jul 2022 13:20:02 -0500 Subject: [SLOF] [PATCH] OF: Add a separate direct kernel loading word In-Reply-To: References: <20220712004624.284935-1-jniethe5@gmail.com> <20220712134819.GL25951@gate.crashing.org> Message-ID: <20220713182002.GT25951@gate.crashing.org> On Wed, Jul 13, 2022 at 01:38:03PM +1000, Jordan Niethe wrote: > Ah ok, it is the first case happening. For example, here the crash > comes after going to $0000000104002f24 > when it should be going to $0000000004002f24. Like this: > > => 0x4002cd8: add r7,r7,r5 > 2: /x $r7 = 0xffff566c A 64-bit program gets that r7 from a sign-extended load (lwa), which would have given 0xffffffffffff566c. A program compiled with -m32 uses lwz here though (there is no lwa on actual 32-bit implementations, and on some implementations lwa is slower than lwz as well). > > "init-program" is supposed to set the MSR state correctly (in ciregs > > >srr1), based on the ELF headers (and btw the same is true for the LE > > flag etc). A little ELF parsing is needed. > > When booting from memory with the -kernel option, qemu has already > loaded the kernel into memory and tells SLOF where to jump into? > SLOF is not looking at the ELF at all in this case is it? But *is* there an ELF loaded, or just a binary blob? If the info is there it would be beneficial to use it, raw blobs have more opportunity to go wrong (and almost no opportunity to report what is wrong). Thanks, Segher From aik at ozlabs.ru Tue Jul 19 14:20:28 2022 From: aik at ozlabs.ru (Alexey Kardashevskiy) Date: Tue, 19 Jul 2022 14:20:28 +1000 Subject: [SLOF] [PATCH] OF: Add a separate direct kernel loading word In-Reply-To: <20220712004624.284935-1-jniethe5@gmail.com> References: <20220712004624.284935-1-jniethe5@gmail.com> Message-ID: On 12/07/2022 10:46, Jordan Niethe wrote: > Currently, go-64 is used for booting a kernel from qemu (i.e. -kernel). > However, there is an expectation from users that this should be able to > boot not just vmlinux kernels but things like Zimages too. > > The bootwrapper of a BE zImage is a 32-bit ELF. Attempting to load that > with go-64 means that it will be ran with MSR_SF set (64-bit mode). This > crashes early in boot (usually due to what should be 32-bit operations > being done with 64-bit registers eventually leading to an incorrect > address being generated and branched to). > > Note that our 64-bit payloads are prepared to enter with MSR_SF cleared > and set it themselves very early. > > Add a new word named go-direct that will execute any simple payload > in-place and will enter with MSR_SF cleared. This allows booting a BE > zImage from qemu with -machine kernel-addr=0. > > Signed-off-by: Jordan Niethe Thanks, applied. > --- > board-qemu/slof/OF.fs | 5 ++--- > slof/fs/boot.fs | 6 ++++++ > 2 files changed, 8 insertions(+), 3 deletions(-) > > diff --git a/board-qemu/slof/OF.fs b/board-qemu/slof/OF.fs > index f0fc9c684b8e..3bcb2af94bdd 100644 > --- a/board-qemu/slof/OF.fs > +++ b/board-qemu/slof/OF.fs > @@ -303,10 +303,9 @@ set-default-console > : (boot-ram) > direct-ram-boot-size 0<> IF > ." Booting from memory..." cr > - s" go-args 2@ " evaluate > - direct-ram-boot-base 0 > + s" direct-ram-boot-base to go-entry" evaluate > s" true state-valid ! " evaluate > - s" disable-watchdog go-64" evaluate > + s" disable-watchdog go-direct" evaluate > THEN > ; > > diff --git a/slof/fs/boot.fs b/slof/fs/boot.fs > index 6d16c54d2af4..a6dfdf3f6c1c 100644 > --- a/slof/fs/boot.fs > +++ b/slof/fs/boot.fs > @@ -112,6 +112,12 @@ defer go ( -- ) > claim-list elf-release 0 to claim-list > ; > > +: go-direct ( -- ) > + 0 ciregs >r3 ! 0 ciregs >r4 ! 0 ciregs >r2 ! > + msr@ 7fffffffffffffff and 2000 or ciregs >srr1 ! > + go-args 2@ go-entry call-client > +; > + > : set-le ( -- ) > 1 ciregs >r13 ! > ; -- Alexey