Re: Upstream QEMU guest support policy ? Re: [PATCH v3 0/2] spapr: Use vIOMMU translation for virtio by default

["Daniel P. Berrangé" <berrange@redhat.com>]

On Thu, Mar 12, 2020 at 12:08:47PM +1100, David Gibson wrote:
> On Wed, Mar 11, 2020 at 10:01:27AM +0000, Daniel P. Berrangé wrote:
> 65;5803;1c> On Wed, Mar 11, 2020 at 12:12:47PM +1100, David Gibson wrote:
> > > On Tue, Mar 10, 2020 at 11:43:43AM +0000, Daniel P. Berrangé wrote:
> > > > On Thu, Mar 05, 2020 at 03:30:07PM +1100, David Gibson wrote:
> > > > > Upcoming Secure VM support for pSeries machines introduces some
> > > > > complications for virtio, since the transfer buffers need to be
> > > > > explicitly shared so that the hypervisor can access them.
> > > > > 
> > > > > While it's not strictly speaking dependent on it, the fact that virtio
> > > > > devices bypass normal platform IOMMU translation complicates the issue
> > > > > on the guest side.  Since there are some significan downsides to
> > > > > bypassing the vIOMMU anyway, let's just disable that.
> > > > > 
> > > > > There's already a flag to do this in virtio, just turn it on by
> > > > > default for forthcoming pseries machine types.
> > > > 
> > > > Breaking existing guest OS to support a new secure VM feature that
> > > > may not even be used/wanted doesn't seems like a sensible tradeoff
> > > > for default out of the box behaviour.
> > > > 
> > > > IOW, if Secure VM needs this, can we tie the change in virtio and
> > > > IOMMU defaults to the machine type flag that enables the use of
> > > > Secure VM.
> > > 
> > > There is no such flag.
> > > 
> > > In the POWER secure VM model, the secure mode option isn't something
> > > that's constructed in when the hypervisor builds the VM.  Instead the
> > > VM is started normally and transitions itself to secure mode by
> > > talking directly with the ultravisor (it then uses TPM shenannigans to
> > > safely get the keys to its real storage backend(s)).
> > 
> > This is pretty suprising to me. The ability to use secure VM mode surely
> > depends on host hardware features. We would need to be able to block the
> > use of this, in order to allow VMs to be live migrated to hosts which
> > lack the feature. Automatically & silently enabling a feature that
> > has a hardware dependancy is something we aim to avoid, unless the user
> > has opted in via some flag (such as -cpu host, or a -cpu $NAME, that
> > implies the feature).
> 
> That is an excellent point, which I had not previously considered.
> 
> I have confirmed that there is indeed not, at present, a way to
> disable the secure transition.  But, it looks like it's not too late
> to fix it.
> 
> I've discussed with Paul Mackerras, and early in the secure transition
> apparently the UV makes a call to the HV, which is allowed to fail.
> 
> So, we're looking at adding another KVM capability for secure mode.
> It will default to disabled, and until it is explicitly enabled, KVM
> will always fail that call from the UV, effectively preventing guests
> from going into secure mode.
> 
> We can then wire that up to a new spapr cap in qemu, which we can also
> use to configure these virtio defaults.

Great, that sounds viable to me.

Regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|