| Message ID | 20200721103202.30610-1-borntraeger@de.ibm.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | [1/1] s390x/protvirt: allow to IPL secure execution guests with -no-reboot | expand |
On 7/21/20 12:32 PM, Christian Borntraeger wrote: > Right now -no-reboot does prevent secure execution guests from running. > This is right from an implementation aspect, as we have modeled the > transition from non-secure to secure as a program directed IPL. > From a user perspective, this is not the behavior of least surprise. > > We should implement the IPL into secure mode similar to the functions > that we use for kdump/kexec. In other words we do not stop here when > -no-reboot is specified on the command line. Like function 0 or function > 1 Function 10 is not a classic reboot. For example it can only be called > once. To call it a 2nd time a real reboot/reset must happen in-between. > So function code 10 is more or less a state transition reset, but not a > "standard" reset or reboot. > > Fixes: 4d226deafc44 ("s390x: protvirt: Support unpack facility") > Signed-off-by: Christian Borntraeger <borntraeger@de.ibm.com> > --- > hw/s390x/ipl.c | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > > diff --git a/hw/s390x/ipl.c b/hw/s390x/ipl.c > index ce21494c08..e312a35133 100644 > --- a/hw/s390x/ipl.c > +++ b/hw/s390x/ipl.c > @@ -633,7 +633,8 @@ void s390_ipl_reset_request(CPUState *cs, enum s390_reset reset_type) > } > } > if (reset_type == S390_RESET_MODIFIED_CLEAR || > - reset_type == S390_RESET_LOAD_NORMAL) { > + reset_type == S390_RESET_LOAD_NORMAL || > + reset_type == S390_RESET_PV) { > /* ignore -no-reboot, send no event */ > qemu_system_reset_request(SHUTDOWN_CAUSE_SUBSYSTEM_RESET); > } else { > I agree that the observable behavior is more logical this way, as the transition to secure mode is more like to kexec (transfer control to an in-memory kernel) than to the other IPL methods (boot from a device). Acked-by: Viktor Mihajlovski <mihajlov@linux.ibm.com>
On 21.07.20 12:32, Christian Borntraeger wrote: > Right now -no-reboot does prevent secure execution guests from running. > This is right from an implementation aspect, as we have modeled the > transition from non-secure to secure as a program directed IPL. > From a user perspective, this is not the behavior of least surprise. > > We should implement the IPL into secure mode similar to the functions > that we use for kdump/kexec. In other words we do not stop here when > -no-reboot is specified on the command line. Like function 0 or function > 1 Function 10 is not a classic reboot. For example it can only be called > once. To call it a 2nd time a real reboot/reset must happen in-between. > So function code 10 is more or less a state transition reset, but not a > "standard" reset or reboot. > > Fixes: 4d226deafc44 ("s390x: protvirt: Support unpack facility") > Signed-off-by: Christian Borntraeger <borntraeger@de.ibm.com> > --- > hw/s390x/ipl.c | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > > diff --git a/hw/s390x/ipl.c b/hw/s390x/ipl.c > index ce21494c08..e312a35133 100644 > --- a/hw/s390x/ipl.c > +++ b/hw/s390x/ipl.c > @@ -633,7 +633,8 @@ void s390_ipl_reset_request(CPUState *cs, enum s390_reset reset_type) > } > } > if (reset_type == S390_RESET_MODIFIED_CLEAR || > - reset_type == S390_RESET_LOAD_NORMAL) { > + reset_type == S390_RESET_LOAD_NORMAL || > + reset_type == S390_RESET_PV) { > /* ignore -no-reboot, send no event */ > qemu_system_reset_request(SHUTDOWN_CAUSE_SUBSYSTEM_RESET); > } else { > Reviewed-by: David Hildenbrand <david@redhat.com>
On 7/21/20 12:32 PM, Christian Borntraeger wrote: > Right now -no-reboot does prevent secure execution guests from running. s/-no-reboot/--no-reboot/ > This is right from an implementation aspect, as we have modeled the > transition from non-secure to secure as a program directed IPL. s/secure/protected/ > From a user perspective, this is not the behavior of least surprise. > > We should implement the IPL into secure mode similar to the functions s/secure/protected/ > that we use for kdump/kexec. In other words we do not stop here when > -no-reboot is specified on the command line. Like function 0 or function > 1 Function 10 is not a classic reboot. For example it can only be called s/Function/function/ and maybe also add a comma > once. To call it a 2nd time a real reboot/reset must happen in-between. > So function code 10 is more or less a state transition reset, but not a > "standard" reset or reboot. > > Fixes: 4d226deafc44 ("s390x: protvirt: Support unpack facility") > Signed-off-by: Christian Borntraeger <borntraeger@de.ibm.com> Reviewed-by: Janosch Frank <frankja@linux.ibm.com> > --- > hw/s390x/ipl.c | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > > diff --git a/hw/s390x/ipl.c b/hw/s390x/ipl.c > index ce21494c08..e312a35133 100644 > --- a/hw/s390x/ipl.c > +++ b/hw/s390x/ipl.c > @@ -633,7 +633,8 @@ void s390_ipl_reset_request(CPUState *cs, enum s390_reset reset_type) > } > } > if (reset_type == S390_RESET_MODIFIED_CLEAR || > - reset_type == S390_RESET_LOAD_NORMAL) { > + reset_type == S390_RESET_LOAD_NORMAL || > + reset_type == S390_RESET_PV) { > /* ignore -no-reboot, send no event */ > qemu_system_reset_request(SHUTDOWN_CAUSE_SUBSYSTEM_RESET); > } else { >
On 21.07.20 14:25, Janosch Frank wrote: > On 7/21/20 12:32 PM, Christian Borntraeger wrote: >> Right now -no-reboot does prevent secure execution guests from running. > > s/-no-reboot/--no-reboot/ Actually qemu --help gives the parameters with just one "-" Not sure about secure vs protected. Whatever Conny prefers.
On Tue, 21 Jul 2020 14:29:29 +0200 Christian Borntraeger <borntraeger@de.ibm.com> wrote: > On 21.07.20 14:25, Janosch Frank wrote: > > On 7/21/20 12:32 PM, Christian Borntraeger wrote: > >> Right now -no-reboot does prevent secure execution guests from running. > > > > s/-no-reboot/--no-reboot/ > > Actually qemu --help gives the parameters with just one "-" > > > Not sure about secure vs protected. Whatever Conny prefers. The doc seems to talk about "protected virtualization", "protected mode", and "secure guests". What about (slight rewording): "s390x/protvirt: allow to IPL secure guests with -no-reboot Right now, -no-reboot prevents secure guests from running. This is correct from an implementation point of view, as we have modeled the transition from non-secure to secure as a program directed IPL. From a user perspective, this is not the behavior of least surprise. We should implement the IPL into protected mode similar to the functions that we use for kdump/kexec. In other words, we do not stop here when -no-reboot is specified on the command line. Like function 0 or function 1, function 10 is not a classic reboot. For example, it can only be called once. Before calling it a second time, a real reboot/reset must happen in-between. So function code 10 is more or less a state transition reset, but not a "standard" reset or reboot." I think this is still appropriate for hard freeze.
On 23.07.20 17:05, Cornelia Huck wrote: > On Tue, 21 Jul 2020 14:29:29 +0200 > Christian Borntraeger <borntraeger@de.ibm.com> wrote: > >> On 21.07.20 14:25, Janosch Frank wrote: >>> On 7/21/20 12:32 PM, Christian Borntraeger wrote: >>>> Right now -no-reboot does prevent secure execution guests from running. >>> >>> s/-no-reboot/--no-reboot/ >> >> Actually qemu --help gives the parameters with just one "-" >> >> >> Not sure about secure vs protected. Whatever Conny prefers. > > The doc seems to talk about "protected virtualization", "protected > mode", and "secure guests". What about (slight rewording): > > "s390x/protvirt: allow to IPL secure guests with -no-reboot > > Right now, -no-reboot prevents secure guests from running. This is > correct from an implementation point of view, as we have modeled the > transition from non-secure to secure as a program directed IPL. From a > user perspective, this is not the behavior of least surprise. > > We should implement the IPL into protected mode similar to the functions > that we use for kdump/kexec. In other words, we do not stop here when > -no-reboot is specified on the command line. Like function 0 or function > 1, function 10 is not a classic reboot. For example, it can only be called > once. Before calling it a second time, a real reboot/reset must happen > in-between. So function code 10 is more or less a state transition > reset, but not a "standard" reset or reboot." > > I think this is still appropriate for hard freeze. i agree. Can you pick this up and fixup the patch description according to your preference? Your proposal looks fine.
On Tue, 21 Jul 2020 06:32:02 -0400 Christian Borntraeger <borntraeger@de.ibm.com> wrote: > Right now -no-reboot does prevent secure execution guests from running. > This is right from an implementation aspect, as we have modeled the > transition from non-secure to secure as a program directed IPL. > From a user perspective, this is not the behavior of least surprise. > > We should implement the IPL into secure mode similar to the functions > that we use for kdump/kexec. In other words we do not stop here when > -no-reboot is specified on the command line. Like function 0 or function > 1 Function 10 is not a classic reboot. For example it can only be called > once. To call it a 2nd time a real reboot/reset must happen in-between. > So function code 10 is more or less a state transition reset, but not a > "standard" reset or reboot. > > Fixes: 4d226deafc44 ("s390x: protvirt: Support unpack facility") > Signed-off-by: Christian Borntraeger <borntraeger@de.ibm.com> > --- > hw/s390x/ipl.c | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > > diff --git a/hw/s390x/ipl.c b/hw/s390x/ipl.c > index ce21494c08..e312a35133 100644 > --- a/hw/s390x/ipl.c > +++ b/hw/s390x/ipl.c > @@ -633,7 +633,8 @@ void s390_ipl_reset_request(CPUState *cs, enum s390_reset reset_type) > } > } > if (reset_type == S390_RESET_MODIFIED_CLEAR || > - reset_type == S390_RESET_LOAD_NORMAL) { > + reset_type == S390_RESET_LOAD_NORMAL || > + reset_type == S390_RESET_PV) { > /* ignore -no-reboot, send no event */ > qemu_system_reset_request(SHUTDOWN_CAUSE_SUBSYSTEM_RESET); > } else { Thanks, queued to s390-fixes.
diff --git a/hw/s390x/ipl.c b/hw/s390x/ipl.c index ce21494c08..e312a35133 100644 --- a/hw/s390x/ipl.c +++ b/hw/s390x/ipl.c @@ -633,7 +633,8 @@ void s390_ipl_reset_request(CPUState *cs, enum s390_reset reset_type) } } if (reset_type == S390_RESET_MODIFIED_CLEAR || - reset_type == S390_RESET_LOAD_NORMAL) { + reset_type == S390_RESET_LOAD_NORMAL || + reset_type == S390_RESET_PV) { /* ignore -no-reboot, send no event */ qemu_system_reset_request(SHUTDOWN_CAUSE_SUBSYSTEM_RESET); } else {
Right now -no-reboot does prevent secure execution guests from running. This is right from an implementation aspect, as we have modeled the transition from non-secure to secure as a program directed IPL. From a user perspective, this is not the behavior of least surprise. We should implement the IPL into secure mode similar to the functions that we use for kdump/kexec. In other words we do not stop here when -no-reboot is specified on the command line. Like function 0 or function 1 Function 10 is not a classic reboot. For example it can only be called once. To call it a 2nd time a real reboot/reset must happen in-between. So function code 10 is more or less a state transition reset, but not a "standard" reset or reboot. Fixes: 4d226deafc44 ("s390x: protvirt: Support unpack facility") Signed-off-by: Christian Borntraeger <borntraeger@de.ibm.com> --- hw/s390x/ipl.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)