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

[Joao Martins]

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.