All of lore.kernel.org
 help / color / mirror / Atom feed
From: Christian Borntraeger <borntraeger@de.ibm.com>
To: Thomas Huth <thuth@redhat.com>,
	Eric Farman <farman@linux.ibm.com>,
	Cornelia Huck <cohuck@redhat.com>
Cc: Jason Herne <jjherne@linux.ibm.com>,
	qemu-s390x@nongnu.org, Janosch Frank <frankja@linux.ibm.com>,
	Matthew Rosato <mjrosato@linux.ibm.com>,
	qemu-devel@nongnu.org
Subject: Re: [PATCH v2 2/2] pc-bios: s390x: Clear out leftover S390EP string
Date: Mon, 23 Nov 2020 09:07:49 +0100	[thread overview]
Message-ID: <1ad47eb6-5aca-a766-3bad-aa38924b5ef8@de.ibm.com> (raw)
In-Reply-To: <4738082f-ec10-e2a3-7756-9180a57329bb@redhat.com>



On 23.11.20 09:05, Thomas Huth wrote:
> On 23/11/2020 08.39, Christian Borntraeger wrote:
>> 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?
> 
> Do these scenarios really go through the s390-ccw bios again, or do they
> rather bypass the bios and jump directly into the new kernel?

Right they jump directly into the new kernel. So this patch could actually
be "good enough" for 5.2 as is?


  reply	other threads:[~2020-11-23  8:09 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-11-20 16:01 [PATCH v2 0/2] pc-bios/s390 fixes for reboot-to-vfio-ccw Eric Farman
2020-11-20 16:01 ` [PATCH v2 1/2] pc-bios: s390x: Ensure Read IPL memory is clean Eric Farman
2020-11-20 16:01 ` [PATCH v2 2/2] pc-bios: s390x: Clear out leftover S390EP string Eric Farman
2020-11-23  7:39   ` Christian Borntraeger
2020-11-23  8:05     ` Thomas Huth
2020-11-23  8:07       ` Christian Borntraeger [this message]
2020-11-23  8:12         ` Thomas Huth

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1ad47eb6-5aca-a766-3bad-aa38924b5ef8@de.ibm.com \
    --to=borntraeger@de.ibm.com \
    --cc=cohuck@redhat.com \
    --cc=farman@linux.ibm.com \
    --cc=frankja@linux.ibm.com \
    --cc=jjherne@linux.ibm.com \
    --cc=mjrosato@linux.ibm.com \
    --cc=qemu-devel@nongnu.org \
    --cc=qemu-s390x@nongnu.org \
    --cc=thuth@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.