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