src/libxl/libxl_conf.c | 9 ++++ src/xenconfig/xen_xl.c | 41 +++++++++++++++++ tests/xlconfigdata/test-fullvirt-nestedhvm.cfg | 26 +++++++++++ tests/xlconfigdata/test-fullvirt-nestedhvm.xml | 61 ++++++++++++++++++++++++++ tests/xlconfigtest.c | 1 + 5 files changed, 138 insertions(+) create mode 100644 tests/xlconfigdata/test-fullvirt-nestedhvm.cfg create mode 100644 tests/xlconfigdata/test-fullvirt-nestedhvm.xml
From: Wim ten Have <wim.ten.have@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> Joao Martins (2): libxl: set nestedhvm when vmx|svm is required xenconfig: add conversion of domxml nestedhvm Wim ten Have (1): xlconfigtest: add test and data for 'nestedhvm' support src/libxl/libxl_conf.c | 9 ++++ src/xenconfig/xen_xl.c | 41 +++++++++++++++++ tests/xlconfigdata/test-fullvirt-nestedhvm.cfg | 26 +++++++++++ tests/xlconfigdata/test-fullvirt-nestedhvm.xml | 61 ++++++++++++++++++++++++++ tests/xlconfigtest.c | 1 + 5 files changed, 138 insertions(+) create mode 100644 tests/xlconfigdata/test-fullvirt-nestedhvm.cfg create mode 100644 tests/xlconfigdata/test-fullvirt-nestedhvm.xml -- 2.9.3 -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
On Wed, Mar 08, 2017 at 03:07:12PM +0100, Wim Ten Have wrote: > From: Wim ten Have <wim.ten.have@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. 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. 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@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
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@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). Joao -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
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@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/ :| -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
On 03/08/2017 03:07 PM, Daniel P. Berrange wrote: > 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@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 Cool, thanks! Joao -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
© 2016 - 2024 Red Hat, Inc.