On 04.12.18 14:48, Janosch Frank wrote: > LPAR and z/VM start in esam mode, so we need to switch to z/Arch and > set 64 bit addressing. > > Under Qemu/KVM we already start out with both when being run with the > Qemu --kernel argument or we lack only 64 bit when booting from disk. > > Signed-off-by: Janosch Frank <frankja@xxxxxxxxxxxxx> > --- > s390x/cstart64.S | 9 +++++++++ > 1 file changed, 9 insertions(+) > > diff --git a/s390x/cstart64.S b/s390x/cstart64.S > index abd6b58..80dbcba 100644 > --- a/s390x/cstart64.S > +++ b/s390x/cstart64.S > @@ -20,6 +20,15 @@ > */ > .globl start > start: > + tam # Test for 64 bit addressing (KVM IPL) > + brc 1, start64 # If cc = 3 (64 bit), we have z/Arch Looking at the kernel, we don't have to test for 64bit but can simply do that always unconditionally. SIGP might bail out but we ignore it. sam64 will also simply do nothing. So tam+brc are not necessary. > + /* Switch to z/Architecture mode (64-bit) */ > + slr %r0, %r0 # set cpuid to zero > + lhi %r1, 2 # mode 2 = esame > + sigp %r1, %r0, 0x12 # sigp set arch > + bras %r13,0f > + .fill 16,4,0x0 > +0: lmh %r0,%r15,0(%r13) # clear high-order half of gprs This is just what the kernel does. The ".fill" part is confusing at first, but it is just the data loaded into the high-order halfs (all 0s) (I was told mixing code and data is bad practice, but for some reason people in Linux decided to do it like that (maybe because of some relocation thingy? or because of instruction set restrictions?)) Should we introduce defines for SIGPs? We might have more once we support multiple CPUs eiher way. > sam64 # Set addressing mode to 64 bit > start64: > /* setup stack */ > -- Thanks, David / dhildenb
