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

[Cédric Le Goater]

On 1/17/23 09:40, Janosch Frank wrote:
> On 1/16/23 18:46, 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.
>
> Didn't we establish that you were missing the IOMMU flag so this statement 
> isn't correct anymore?

yes. Which means it is pointless to run the machine because it will fail
to boot with no means to understand why.
 
> I haven't yet fully ingested my coffee, but from what I understand you would 
> block a switch into PV mode if cgs is not set. Which would mean that PV KVM 
> unit tests wouldn't start anymore as well as any VMs that have the unpack 
> feature but not cgs.
>
>
> And that's not something that we want.
>
> You can start a PV VM without cgs if unpack is in the CPU model. The ONLY 
> requirement that we should fail on is unpack.

ok.

> Have a look at what David Gibson put in the commit message when he introduced 
> that in 651615d9:
>
> """
> To integrate this with the option used by other platforms, we
> implement the following compromise:
>
>   - When the confidential-guest-support option is set, s390 will
>     recognize it, verify that the CPU can support PV (failing if not)
>     and set virtio default options necessary for encrypted or protected
>     guests, as on other platforms.  i.e. if confidential-guest-support
>     is set, we will either create a guest capable of entering PV mode,
>     or fail outright.
>
>   - If confidential-guest-support is not set, guests might still be
>     able to enter PV mode, if the CPU has the right model.  This may be
>     a little surprising, but shouldn't actually be harmful.
> """

yes and it is not that clear how a s390 PV machine should be started, even
for a developer.

Thanks for looking,

C.