Re: [PATCH v2 3/4] s390x/pv: Introduce a s390_pv_check() helper for runtime

[Janosch Frank <frankja@linux.ibm.com>]

On 1/9/23 14:30, Cédric Le Goater wrote:
> On 1/9/23 10:49, Janosch Frank wrote:
>> On 1/9/23 10:27, Cédric Le Goater wrote:
>>> On 1/9/23 10:04, Janosch Frank wrote:
>>>> On 1/6/23 08:53, Cédric Le Goater wrote:
>>>>> From: Cédric Le Goater <clg@redhat.com>
>>>>>
>>>>> If a secure kernel is started in a non-protected VM, the OS will hang
>>>>> during boot without giving a proper error message to the user.
>>>>
>>>> Most of the time you see nothing in the console because libvirt is too slow. If you start the VM in paused mode, attach a console and then resume it, then you'll see a nice error message.
>>>
>>> If you wait long enough, the VM fails to mount / and falls into the dracut
>>> initrams.
>>
>> I have the feeling that we're not talking about the same thing here.>
>    > A PV VM always starts out as a non-PV VM and is put into PV mode via two diag308 subcodes (8 & 10). ALL PV subcodes (8 - 10) are spec exceptions if the host isn't enabled for PV.
> 
> The corner case this patch is trying to address is for a PV-enabled host,
> a secure enabled OS and !PV-enabled QEMU.
> 
> Please run this command on a secure disk image :
> 
>     qemu-system-s390x -M s390-ccw-virtio -accel kvm -drive file=<file>,if=virtio,format=qcow2 -nographic -nodefaults -serial mon:stdio
> 
> and tell me what you get.
> 

qemu-system-s390x -M s390-ccw-virtio -accel kvm -drive 
file=u2204.qcow2,if=virtio,format=qcow2 -nographic -nodefaults -serial 
mon:stdio
LOADPARM=[        ]
Using virtio-blk.
Using SCSI scheme.
.............................................................................................................................
Secure unpack facility is not available


> Thanks,
> 
> C.