[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH v2 2/2] pc-bios: s390x: Clear out leftover S390EP string
From: |
Christian Borntraeger |
Subject: |
Re: [PATCH v2 2/2] pc-bios: s390x: Clear out leftover S390EP string |
Date: |
Mon, 23 Nov 2020 08:39:22 +0100 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.3.1 |
On 20.11.20 17:01, Eric Farman wrote:
> A Linux binary will have the string "S390EP" at address 0x10008,
> which is important in getting the guest up off the ground. In the
> case of a reboot (specifically chreipl going to a new device),
> we should defer to the PSW at address zero for the new config,
> which will re-write "S390EP" from the new image.
>
> Let's clear it out at this point so that a reipl to, say, a DASD
> passthrough device drives the IPL path from scratch without disrupting
> disrupting the order of operations for other boots.
>
> Rather than hardcoding the address of this magic (again), let's
> define it somewhere so that the two users are visibly related.
Hmmm, this might have side effects, e.g. if you do something like a kdump
or kexec to a non-Linux binary that happens to have code at 0x10008, no?
As far as I can tell, the problem should only happen for a ccw type IPL
so why not
[...]
> --- a/pc-bios/s390-ccw/main.c
> +++ b/pc-bios/s390-ccw/main.c
> @@ -178,6 +178,12 @@ static void boot_setup(void)
> memcpy(lpmsg + 10, loadparm_str, 8);
> sclp_print(lpmsg);
>
> + /*
> + * Clear out any potential S390EP magic (see jump_to_low_kernel()),
> + * so we don't taint our decision-making process during a reboot.
> + */
> + memset((char *)S390EP, 0, 6);
move this into find_subch
in here:
------------- snip ---------------
case CU_TYPE_DASD_3990:
case CU_TYPE_DASD_2107:
return true;
------------- snip ---------------