[libvirt] [PATCH v1 0/3] libxl: nestedhvm support

[Daniel P. Berrange]

On Wed, Mar 08, 2017 at 03:09:11PM +0000, Joao Martins wrote:
> On 03/08/2017 02:13 PM, Daniel P. Berrange wrote:
> > On Wed, Mar 08, 2017 at 03:07:12PM +0100, Wim Ten Have wrote:
> >> From: Wim ten Have <wim.ten.have at oracle.com>
> >>
> >> This patch enhances host-passthrough capability to advertise the
> >> required vendor CPU virtualization feature which will be used to
> >> enable 'nestedhvm' in the libxl driver.
> >>
> >> For Intel virtualization (VT-x)
> >>     ..
> >>   <cpu mode='host-passthrough'>
> >>     <feature policy='require' name='vmx'/>
> >>   </cpu>
> >>
> >> For AMD virtualization (AMD-V)
> >>     ..
> >>   <cpu mode='host-passthrough'>
> >>     <feature policy='require' name='svm'/>
> >>   </cpu>
> > 
> > If using host-passthrough or host-model, and the host's CPU includes
> > vmx or svm, then I would expecte nested-HVM to be enabled, without
> > needing any extra <feature> flag in the XML. That would match the
> > semantics used with the QEMU driver.
> > 
> > The only time we would need to use <feature> is if using mode=custom
> > along with a named CPU model which lacks vmx/svm flags.
> Ah OK - I was kinda off unclear on that. So using host-passthrough should be
> enough then. (while making sure libxl checks if host->cpu does have vmx or svm
> in its features)
> 
> > BTW, I wonder how hard it would be to wire up the libxl driver to use
> > the CPU model infrastructure in src/cpu ? It feels a little odd to use
> > XML <cpu mode='host-passthrough'/> if we're not then making sure it
> > actually uses host-passthrough when configuring the guest.
> While xen libxl do allow to mangle the cpuid, it is meant for disabling features
> at this point. libxl follows a "host-model" first, meaning the default is to
> expose as much as features as possible to the guest (depending on whether it's
> PV or HVM). However, nested virt is a slightly special case since the toolstack
> will do more than simply unmasking vmx/svm bits (actually within libxl, a sysctl
> to Xen is performed to enable nested virt to the domain, in which case libxc
> will handle any vendor specific bits). IOW, even when we improve libxl cpuid
> policy management to the point we can wire up to libvirt cpu model
> infrastruture, we would still need to handle the nestedhvm special case (which
> btw this field would work even for ARM whenever supported).

Yep, I see. So with libxl using host-model by default, then

 - If the host CPU includes svm/vmx, turn on nested virt in the guest
 - Allow use of <feature name="vmx" policy="disable"/> to block nested
   virt in the guest, even if available in host CPU

Regards,
Daniel
-- 
|: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org              -o-             http://virt-manager.org :|
|: http://entangle-photo.org       -o-    http://search.cpan.org/~danberr/ :|