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

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.

'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.

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.