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. > If you want to not expose svm/vmx to the guest, despite it being available > in the host, then use feature policy=disble when configuring it. > >> (I think you propose policy='force' here which is probably better suited as >> opposed to policy='require') > > It depends on what semantics the Xen hypervisor provides. > > 'require' means expose the feature to the guest if it is supported > by the host, but raise an error if the host doesn't support it. > > 'force' means expose the feature to the guest, even if the host does > not support it at all. > > For HVM Xen guests there's no real distinction between these, as you > can't run an HVM Xen guest without having hardware virt in your > host. So for 'vmx' / 'svm' force/require are basically the same > thing. For other CPU feature bits they are definitely different. -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
