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 :|