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

[Cédric Le Goater]

On 1/9/23 15:52, Janosch Frank wrote:
> On 1/9/23 15:31, Janosch Frank wrote:
> > On 1/9/23 14:53, Cédric Le Goater wrote:
> > > On 1/9/23 14:45, Janosch Frank wrote:
> > > > 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
> > >
> > > Yes. That's with a !PV-enabled host. Correct ?
> > >
> > > Can you try with prot_virt=1 on the host please ?
> >
> > With prot_virt=1 it boots until it doesn't find the file system (at
> > least if you give it a bit more memory than the standard 256MB):
> >
> > qemu-system-s390x -M s390-ccw-virtio -accel kvm -drive
> > file=u2204.qcow2,if=virtio,format=qcow2 -nographic -nodefaults -serial
> > mon:stdio -m 4096
> > [Linux boot stuff]
> > ALERT!  /dev/disk/by-path/ccw-0.0.0000-part1 does not exist.  Dropping
> > to a shell!
>
> I.e. it boots into secure mode just fine.
>
> Now if you add iommu_platform=true to the device then it'll even boot from disk.
>
> So we'd rather need an error message if you attach a device without the iommu 
> being set to true. The whole topic of PV iommu problems has a few windings 
> which I don't fully want to bring to electronic paper right now.
>
> Either you start a secure guest that has devices with manual iommu entries or 
> you go the launch security route and let libvirt/qemu handle it for you.

aaahh. So "-machine confidential-guest-support=pv0 -object s390-pv-guest,id=pv0"
is equivalent to "-global virtio-device.iommu_platform=true". I should have
looked closer :/

Thanks for the clarification,

C.