| Message ID | 20181218092657.46466-5-frankja@linux.ibm.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | 390x: Add cross hypervisor and disk boot | expand |
On 18.12.18 10:26, Janosch Frank wrote: s/s390x: Switch to z\/Arch if needed/s390x: Switch to z\/Arch/ As you dropped the condition before the switch > LPAR and z/VM start in esam mode depending on the hardware, 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 64 bit when booting from disk > because of the initial psw specifying 31 bit for z/VM and lpar > compatibility. > > Signed-off-by: Janosch Frank <frankja@linux.ibm.com> > Reviewed-by: David Hildenbrand <david@redhat.com> > --- > s390x/cstart64.S | 8 ++++++++ > 1 file changed, 8 insertions(+) > > diff --git a/s390x/cstart64.S b/s390x/cstart64.S > index d382497..7886f35 100644 > --- a/s390x/cstart64.S > +++ b/s390x/cstart64.S > @@ -20,9 +20,17 @@ > * > * For KVM and TCG kernel boot we are in 64 bit z/Arch mode. > * When booting from disk the initial short psw is in 31 bit mode. > + * When running under LPAR or z/VM, we might start in 31 bit and esam mode. > */ > .globl start > start: > + /* Switch to z/Architecture mode and 64-bit */ > + slr %r0, %r0 # Set cpuid to zero > + lhi %r1, 2 # mode 2 = esame > + sigp %r1, %r0, 0x12 # sigp set arch Use the new define for set architecture here? > + bras %r13,0f # Jump over zero area > + .fill 16,4,0x0 # Zero area for lmh > +0: lmh %r0,%r15,0(%r13) # Clear high-order half of gprs > sam64 # Set addressing mode to 64 bit > /* setup stack */ > larl %r15, stackptr >
On 18.12.18 10:54, David Hildenbrand wrote: > On 18.12.18 10:26, Janosch Frank wrote: > > s/s390x: Switch to z\/Arch if needed/s390x: Switch to z\/Arch/ > > As you dropped the condition before the switch > >> LPAR and z/VM start in esam mode depending on the hardware, 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 64 bit when booting from disk >> because of the initial psw specifying 31 bit for z/VM and lpar >> compatibility. >> >> Signed-off-by: Janosch Frank <frankja@linux.ibm.com> >> Reviewed-by: David Hildenbrand <david@redhat.com> >> --- >> s390x/cstart64.S | 8 ++++++++ >> 1 file changed, 8 insertions(+) >> >> diff --git a/s390x/cstart64.S b/s390x/cstart64.S >> index d382497..7886f35 100644 >> --- a/s390x/cstart64.S >> +++ b/s390x/cstart64.S >> @@ -20,9 +20,17 @@ >> * >> * For KVM and TCG kernel boot we are in 64 bit z/Arch mode. >> * When booting from disk the initial short psw is in 31 bit mode. >> + * When running under LPAR or z/VM, we might start in 31 bit and esam mode. >> */ >> .globl start >> start: >> + /* Switch to z/Architecture mode and 64-bit */ >> + slr %r0, %r0 # Set cpuid to zero >> + lhi %r1, 2 # mode 2 = esame >> + sigp %r1, %r0, 0x12 # sigp set arch > > Use the new define for set architecture here? Will do > >> + bras %r13,0f # Jump over zero area >> + .fill 16,4,0x0 # Zero area for lmh >> +0: lmh %r0,%r15,0(%r13) # Clear high-order half of gprs >> sam64 # Set addressing mode to 64 bit >> /* setup stack */ >> larl %r15, stackptr >> > >
On 2018-12-18 10:26, Janosch Frank wrote: > LPAR and z/VM start in esam mode depending on the hardware, 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 64 bit when booting from disk > because of the initial psw specifying 31 bit for z/VM and lpar > compatibility. > > Signed-off-by: Janosch Frank <frankja@linux.ibm.com> > Reviewed-by: David Hildenbrand <david@redhat.com> > --- > s390x/cstart64.S | 8 ++++++++ > 1 file changed, 8 insertions(+) > > diff --git a/s390x/cstart64.S b/s390x/cstart64.S > index d382497..7886f35 100644 > --- a/s390x/cstart64.S > +++ b/s390x/cstart64.S > @@ -20,9 +20,17 @@ > * > * For KVM and TCG kernel boot we are in 64 bit z/Arch mode. > * When booting from disk the initial short psw is in 31 bit mode. > + * When running under LPAR or z/VM, we might start in 31 bit and esam mode. > */ > .globl start > start: > + /* Switch to z/Architecture mode and 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 # Jump over zero area > + .fill 16,4,0x0 # Zero area for lmh > +0: lmh %r0,%r15,0(%r13) # Clear high-order half of gprs Do we really want to keep the lmh here? ... yes, I know the kernel is doing this, too, but I really fail to see why we would need it in the kvm-unit-tests, too... have you tried it also without this clearing? Thomas
On 18.12.18 11:04, Thomas Huth wrote: > On 2018-12-18 10:26, Janosch Frank wrote: >> LPAR and z/VM start in esam mode depending on the hardware, 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 64 bit when booting from disk >> because of the initial psw specifying 31 bit for z/VM and lpar >> compatibility. >> >> Signed-off-by: Janosch Frank <frankja@linux.ibm.com> >> Reviewed-by: David Hildenbrand <david@redhat.com> >> --- >> s390x/cstart64.S | 8 ++++++++ >> 1 file changed, 8 insertions(+) >> >> diff --git a/s390x/cstart64.S b/s390x/cstart64.S >> index d382497..7886f35 100644 >> --- a/s390x/cstart64.S >> +++ b/s390x/cstart64.S >> @@ -20,9 +20,17 @@ >> * >> * For KVM and TCG kernel boot we are in 64 bit z/Arch mode. >> * When booting from disk the initial short psw is in 31 bit mode. >> + * When running under LPAR or z/VM, we might start in 31 bit and esam mode. >> */ >> .globl start >> start: >> + /* Switch to z/Architecture mode and 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 # Jump over zero area >> + .fill 16,4,0x0 # Zero area for lmh >> +0: lmh %r0,%r15,0(%r13) # Clear high-order half of gprs > > Do we really want to keep the lmh here? ... yes, I know the kernel is > doing this, too, but I really fail to see why we would need it in the > kvm-unit-tests, too... have you tried it also without this clearing? > > Thomas > I think I had it without that for a few days. What's your reasoning against it? We loose more cycles when clearing BSS under KVM where it's empty anyway. I'd rather expand it to a lm, to really have a fresh start.
On 2018-12-18 12:45, Janosch Frank wrote: > On 18.12.18 11:04, Thomas Huth wrote: >> On 2018-12-18 10:26, Janosch Frank wrote: >>> LPAR and z/VM start in esam mode depending on the hardware, 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 64 bit when booting from disk >>> because of the initial psw specifying 31 bit for z/VM and lpar >>> compatibility. >>> >>> Signed-off-by: Janosch Frank <frankja@linux.ibm.com> >>> Reviewed-by: David Hildenbrand <david@redhat.com> >>> --- >>> s390x/cstart64.S | 8 ++++++++ >>> 1 file changed, 8 insertions(+) >>> >>> diff --git a/s390x/cstart64.S b/s390x/cstart64.S >>> index d382497..7886f35 100644 >>> --- a/s390x/cstart64.S >>> +++ b/s390x/cstart64.S >>> @@ -20,9 +20,17 @@ >>> * >>> * For KVM and TCG kernel boot we are in 64 bit z/Arch mode. >>> * When booting from disk the initial short psw is in 31 bit mode. >>> + * When running under LPAR or z/VM, we might start in 31 bit and esam mode. >>> */ >>> .globl start >>> start: >>> + /* Switch to z/Architecture mode and 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 # Jump over zero area >>> + .fill 16,4,0x0 # Zero area for lmh >>> +0: lmh %r0,%r15,0(%r13) # Clear high-order half of gprs >> >> Do we really want to keep the lmh here? ... yes, I know the kernel is >> doing this, too, but I really fail to see why we would need it in the >> kvm-unit-tests, too... have you tried it also without this clearing? > > I think I had it without that for a few days. > What's your reasoning against it? It just looks weird this way. Like we wanted to execute some 32-bit code in 64-bit mode afterwards, but we don't do that. > We loose more cycles when clearing BSS > under KVM where it's empty anyway. I'd rather expand it to a lm, to > really have a fresh start. Fine for me, just add a comment like that ("Clear all registers to make sure that we have a well-defined fresh start" or so). I think I'd also rather write this as: .irp i, 0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15 xgr \i,\i .endr ... since that takes a little bit less space. Thomas
diff --git a/s390x/cstart64.S b/s390x/cstart64.S index d382497..7886f35 100644 --- a/s390x/cstart64.S +++ b/s390x/cstart64.S @@ -20,9 +20,17 @@ * * For KVM and TCG kernel boot we are in 64 bit z/Arch mode. * When booting from disk the initial short psw is in 31 bit mode. + * When running under LPAR or z/VM, we might start in 31 bit and esam mode. */ .globl start start: + /* Switch to z/Architecture mode and 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 # Jump over zero area + .fill 16,4,0x0 # Zero area for lmh +0: lmh %r0,%r15,0(%r13) # Clear high-order half of gprs sam64 # Set addressing mode to 64 bit /* setup stack */ larl %r15, stackptr