qemu-s390x
[Top][All Lists]
Advanced

[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 ---------------




reply via email to

[Prev in Thread] Current Thread [Next in Thread]