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@xxxxxxxxxxxxx> >> Reviewed-by: David Hildenbrand <david@xxxxxxxxxx> >> --- >> 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.
Attachment:
signature.asc
Description: OpenPGP digital signature
