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 :| -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list
