On Mon, Aug 03, 2020 at 10:07:42AM +0200, Janosch Frank wrote:
> On 8/3/20 9:54 AM, David Gibson wrote:
> > On Mon, Aug 03, 2020 at 09:49:42AM +0200, Janosch Frank wrote:
> >> On 7/24/20 4:57 AM, David Gibson wrote:
> >>> At least some s390 cpu models support "Protected Virtualization" (PV),
> >>> a mechanism to protect guests from eavesdropping by a compromised
> >>> hypervisor.
> >>>
> >>> This is similar in function to other mechanisms like AMD's SEV and
> >>> POWER's PEF, which are controlled bythe "host-trust-limitation"
> >>> machine option.  s390 is a slightly special case, because we already
> >>> supported PV, simply by using a CPU model with the required feature
> >>> (S390_FEAT_UNPACK).
> >>>
> >>> To integrate this with the option used by other platforms, we
> >>> implement the following compromise:
> >>>
> >>>  - When the host-trust-limitation 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 host-trust-limitation is set, we
> >>>    will either create a guest capable of entering PV mode, or fail
> >>>    outright
> >>>
> >>>  - If host-trust-limitation is not set, guest's 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.
> >>
> >> As I already explained, they have to continue to work without any change
> >> to the VM's configuration.
> > 
> > Yes.. that's what I'm saying will happen.
> > 
> >> Our users already expect PV to work without HTL. This feature is already
> >> being used and the documentation has been online for a few months. I've
> >> already heard enough complains because users found small errors in our
> >> documentation. I'm not looking forward to complains because suddenly we
> >> need to specify new command line arguments depending on the QEMU version.
> >>
> >> @Cornelia: QEMU is not my expertise, am I missing something here?
> > 
> > What I'm saying here is that you don't need a new option.  I'm only
> > suggesting we make the new option the preferred way for future
> > upstream releases.  (the new option has the advantage that you *just*
> > need to specify it, and any necessary virtio or other options to be
> > compatible should be handled for you).
> > 
> > But existing configurations should work as is (I'm not sure they do
> > with the current patch, because I'm not familiar with the s390 code
> > and have no means to test PV, but that can be sorted out before
> > merge).
> > 
> OK, should and might are two different things so I was a bit concerned.
> That's fine then, thanks for the answer.

Well, the "should" and "might" are covering different things.
Existing working command lines should continue to work.  But those
command lines must already have the necessary tweaks to make virtio
work properly.  If you try to make a new command line for a PV guest
with a virtio device - or anything else that introduces extra PV
complications - then just chosing a CPU model with UNPACK might not be
enough.  By contrast, if you set host-trust-limitation, then it should
work and be PV capable with an arbitrary set of devices, or else fail
immediately with a meaningful error.

-- 
David Gibson			| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au	| minimalist, thank you.  NOT _the_ _other_
				| _way_ _around_!
http://www.ozlabs.org/~dgibson