qemu-s390x
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH 1/1] s390x/protvirt: allow to IPL secure execution guests wit


From: David Hildenbrand
Subject: Re: [PATCH 1/1] s390x/protvirt: allow to IPL secure execution guests with -no-reboot
Date: Tue, 21 Jul 2020 12:55:56 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.9.0

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>

-- 
Thanks,

David / dhildenb




reply via email to

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