[libvirt] [PATCH v3 2/6] libxl: do not enable nested HVM by mere presence of <cpu> element

[Daniel P. Berrange]

On Tue, Dec 19, 2017 at 01:43:24PM +0000, Joao Martins wrote:
> On 12/19/2017 01:13 PM, Daniel P. Berrange wrote:
> > On Tue, Dec 19, 2017 at 01:01:36PM +0000, Joao Martins wrote:
> >> [Sorry for double posting, but I mistakenly forgot to include libvirt list)
> >>
> >> +WimT +Daniel
> >>
> >> On 12/10/2017 02:10 AM, Marek Marczykowski-Górecki wrote:
> >>> <cpu mode='host-passthrough'> element may be used to configure other
> >>> features, like NUMA, or CPUID. Do not enable nested HVM (which is in
> >>> "preview" state after all) by mere presence of
> >>> <cpu mode='host-passthrough'> element, but require explicit <feature
> >>> policy='force' name='vmx'/> (or 'svm').
> >>> Also, adjust xenconfig driver to appropriately translate to/from
> >>> nestedhvm=1.
> >>>
> >>> While at it, adjust xenconfig driver to not override def->cpu if already
> >>> set elsewhere. This will help with adding cpuid support.
> >>
> >> I agree with this and it was what we came up in the first version of nested hvm
> >> support[0]. Although Daniel suggested there to use the same semantics of qemu
> >> driver such that host-passthrough enables nested hvm without the use of:
> >>
> >> <feature policy='require' name='vmx'/>
> > 
> > Yes, the key point of libvirt is to apply consistent semantics across different
> > drivers, so we should not diverge betweeen QEMU & Xen in this regard.
> > 
> 
> /nods
> 
> > 'host-passthrough' and 'host-model' are supposed to expose *every* feature that
> > the host CPUs support (except for those few which the hypervisor may block due
> > to ability to virtualize them).
> > 
> > So 'host-passthrough' is correct to automatically expose vmx/svm, without
> > requiring any extra <feature> element, and I don't think we can accept
> > this patch.
> > 
> > This has been the case for KVM for ages, even though it has been considered
> > experimental.  The only slight difference is that you can block use of svm/vmx
> > at the host OS level via a kernel arg to the kvm modules.
> > 
> Ah that's where Xen falls off a little in which there's only libxl nested_hvm
> field to control it, even though is still marked Experimental. There's no global
> parameter to block it.

You could conceivably replicate the host-level control KVM has by using an
/etc/libvirt/libxl.conf driver level config option to indicate whether
nested-virt is permitted or not.

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