On 10/7/18 9:39 AM, Marek Marczykowski-Górecki wrote:
Since this is something between PV and HVM, it makes sense to put the
setting in place where domain type is specified.
To enable it, use <os><type machine="xenpvh">...</type></os>. It is
also included in capabilities.xml, for every supported HVM guest type - it
doesn't seems to be any other requirement (besides new enough Xen).
Signed-off-by: Marek Marczykowski-Górecki <marmarek@xxxxxxxxxxxxxxxxxxxxxx>
---
Changes in v2 proposed by Jim:
- use new_arch_added var instead of i == nr_guest_archs for clarity
- improve comment
- adjust for now required Xen >= 4.6 (remove part for Xen < 4.5)
Changes in v3:
- limit VIR_DOMAIN_OSTYPE_XEN -> VIR_DOMAIN_OSTYPE_LINUX conversion to
Xen PV only
- do not accept VIR_DOMAIN_OSTYPE_LINUX for PVH
- fix reported capabilities for PVH - remove hostdev passthrough and
video/graphics
- use #ifdef LIBXL_DOMAIN_TYPE_PVH instead of hypervisor version to
check for PVH support
- compile fix for Xen < 4.9
Changes in v4:
- revert to "i == nr_guest_archs-1" check
- let configure check for LIBXL_DOMAIN_TYPE_PVH and use #ifdef
HAVE_XEN_PVH then
- fix comment about Xen version
---
docs/formatcaps.html.in | 4 +--
docs/schemas/domaincommon.rng | 1 +-
m4/virt-driver-libxl.m4 | 3 ++-
src/conf/domain_conf.c | 6 ++--
src/libxl/libxl_capabilities.c | 38 ++++++++++++++++++++++-----
src/libxl/libxl_conf.c | 50 ++++++++++++++++++++++++++++++-----
src/libxl/libxl_driver.c | 6 ++--
7 files changed, 90 insertions(+), 18 deletions(-)
diff --git a/docs/formatcaps.html.in b/docs/formatcaps.html.in
index 0d9c53d..fe113bc 100644
--- a/docs/formatcaps.html.in
+++ b/docs/formatcaps.html.in
@@ -104,8 +104,8 @@
<dt><code>machine</code></dt><dd>Machine type, for use in
<a href="formatdomain.html#attributeOSTypeMachine">machine</a>
attribute of os/type element in domain XML. For example Xen
- supports <code>xenfv</code> for HVM or <code>xenpv</code> for
- PV.</dd>
+ supports <code>xenfv</code> for HVM, <code>xenpv</code> for
+ PV, or <code>xenpvh</code> for PVH.</dd>
<dt><code>domain</code></dt><dd>The <code>type</code> attribute of
this element specifies the type of hypervisor required to run the
domain. Use in <a href="formatdomain.html#attributeDomainType">type</a>
diff --git a/docs/schemas/domaincommon.rng b/docs/schemas/domaincommon.rng
index 099a949..820a7c6 100644
--- a/docs/schemas/domaincommon.rng
+++ b/docs/schemas/domaincommon.rng
@@ -341,6 +341,7 @@
<choice>
<value>xenpv</value>
<value>xenfv</value>
+ <value>xenpvh</value>
</choice>
</attribute>
</optional>
diff --git a/m4/virt-driver-libxl.m4 b/m4/virt-driver-libxl.m4
index 479d911..2cd97cc 100644
--- a/m4/virt-driver-libxl.m4
+++ b/m4/virt-driver-libxl.m4
@@ -75,6 +75,9 @@ AC_DEFUN([LIBVIRT_DRIVER_CHECK_LIBXL], [
])
fi
+ dnl Check if Xen has support for PVH
+ AC_CHECK_DECL(LIBXL_DOMAIN_TYPE_PVH, [AC_DEFINE([HAVE_XEN_PVH], [1], [Define to 1 if Xen has PVH support.])], [], [#include <libxl.h>])
Nice! I was unable to get this to work, probably due to some botched quoting.
+
AC_SUBST([LIBXL_CFLAGS])
AC_SUBST([LIBXL_LIBS])
])
diff --git a/src/conf/domain_conf.c b/src/conf/domain_conf.c
index 9911d56..a945ad4 100644
--- a/src/conf/domain_conf.c
+++ b/src/conf/domain_conf.c
@@ -19094,7 +19094,8 @@ virDomainDefParseCaps(virDomainDefPtr def,
* be 'xen'. So we accept the former and convert
*/
if (def->os.type == VIR_DOMAIN_OSTYPE_LINUX &&
- def->virtType == VIR_DOMAIN_VIRT_XEN) {
+ def->virtType == VIR_DOMAIN_VIRT_XEN &&
+ (!def->os.machine || STREQ(def->os.machine, "xenpv"))) {
def->os.type = VIR_DOMAIN_OSTYPE_XEN;
}
@@ -27705,7 +27706,8 @@ virDomainDefFormatInternal(virDomainDefPtr def,
* be 'xen'. So we convert to the former for backcompat
*/
if (def->virtType == VIR_DOMAIN_VIRT_XEN &&
- def->os.type == VIR_DOMAIN_OSTYPE_XEN)
+ def->os.type == VIR_DOMAIN_OSTYPE_XEN &&
+ (!def->os.machine || STREQ(def->os.machine, "xenpv")))
virBufferAsprintf(buf, ">%s</type>\n",
virDomainOSTypeToString(VIR_DOMAIN_OSTYPE_LINUX));
else
diff --git a/src/libxl/libxl_capabilities.c b/src/libxl/libxl_capabilities.c
index 18596c7..eecd5e9 100644
--- a/src/libxl/libxl_capabilities.c
+++ b/src/libxl/libxl_capabilities.c
@@ -57,6 +57,7 @@ struct guest_arch {
virArch arch;
int bits;
int hvm;
+ int pvh;
int pae;
int nonpae;
int ia64_be;
@@ -491,13 +492,33 @@ libxlCapsInitGuests(libxl_ctx *ctx, virCapsPtr caps)
guest_archs[i].nonpae = nonpae;
if (ia64_be)
guest_archs[i].ia64_be = ia64_be;
+
+ /*
+ * Xen 4.10 introduced support for the PVH guest type, which
+ * requires hardware virtualization support similar to the
+ * HVM guest type. Add a PVH guest type for each new HVM
+ * guest type.
+ */
+#ifdef HAVE_XEN_PVH
+ if (hvm && i == nr_guest_archs-1) {
+ i = nr_guest_archs;
+ /* Ensure we have not exhausted the guest_archs array */
+ if (nr_guest_archs >= ARRAY_CARDINALITY(guest_archs))
+ continue;
+ guest_archs[nr_guest_archs].arch = arch;
+ guest_archs[nr_guest_archs].pvh = 1;
+ nr_guest_archs++;
+ }
+#endif
}
}
regfree(®ex);
for (i = 0; i < nr_guest_archs; ++i) {
virCapsGuestPtr guest;
- char const *const xen_machines[] = {guest_archs[i].hvm ? "xenfv" : "xenpv"};
+ char const *const xen_machines[] = {
+ guest_archs[i].hvm ? "xenfv" :
+ (guest_archs[i].pvh ? "xenpvh" : "xenpv")};
I had some couch time at the start of the weekend and was finally able to try
using this series with virt-install. As it turns out, reporting duplicate
<guest> blocks for <os_type> 'xen' is not quite right. Instead we will want to
report the additional <machine> under the existing 'xen' <guest> blocks. E.g.
instead of adding a duplicate
<guest>
<os_type>xen</os_type>
<arch name='x86_64'>
<wordsize>64</wordsize>
<emulator>/usr/lib/xen/bin/qemu-system-i386</emulator>
<machine>xenpvh</machine>
<domain type='xen'/>
</arch>
...
</guest>
we'll want to include the xenpvh machine in the existing <guest> config for xen
<guest>
<os_type>xen</os_type>
<arch name='x86_64'>
<wordsize>64</wordsize>
<emulator>/usr/lib/xen/bin/qemu-system-i386</emulator>
<machine>xenpvh</machine>
<machine>xenpv</machine>
<domain type='xen'/>
</arch>
</guest>
With this change to the capabilities reporting, virt-install works without
modification using
virt-install --paravirt --machine xenpv ...
I didn't think too hard about the best way to handle this, but the attached diff
is a POC hack that works with unmodified virt-install.
Regards,
Jim
diff --git a/src/libxl/libxl_capabilities.c b/src/libxl/libxl_capabilities.c
index eecd5e94fb..1400094742 100644
--- a/src/libxl/libxl_capabilities.c
+++ b/src/libxl/libxl_capabilities.c
@@ -492,24 +492,6 @@ libxlCapsInitGuests(libxl_ctx *ctx, virCapsPtr caps)
guest_archs[i].nonpae = nonpae;
if (ia64_be)
guest_archs[i].ia64_be = ia64_be;
-
- /*
- * Xen 4.10 introduced support for the PVH guest type, which
- * requires hardware virtualization support similar to the
- * HVM guest type. Add a PVH guest type for each new HVM
- * guest type.
- */
-#ifdef HAVE_XEN_PVH
- if (hvm && i == nr_guest_archs-1) {
- i = nr_guest_archs;
- /* Ensure we have not exhausted the guest_archs array */
- if (nr_guest_archs >= ARRAY_CARDINALITY(guest_archs))
- continue;
- guest_archs[nr_guest_archs].arch = arch;
- guest_archs[nr_guest_archs].pvh = 1;
- nr_guest_archs++;
- }
-#endif
}
}
regfree(®ex);
@@ -517,11 +499,11 @@ libxlCapsInitGuests(libxl_ctx *ctx, virCapsPtr caps)
for (i = 0; i < nr_guest_archs; ++i) {
virCapsGuestPtr guest;
char const *const xen_machines[] = {
- guest_archs[i].hvm ? "xenfv" :
- (guest_archs[i].pvh ? "xenpvh" : "xenpv")};
+ guest_archs[i].hvm ? "xenfv" : "xenpvh", "xenpv"};
+ int nmachines = guest_archs[i].hvm ? 1 : 2;
virCapsGuestMachinePtr *machines;
- if ((machines = virCapabilitiesAllocMachines(xen_machines, 1)) == NULL)
+ if ((machines = virCapabilitiesAllocMachines(xen_machines, nmachines)) == NULL)
return -1;
if ((guest = virCapabilitiesAddGuest(caps,
@@ -531,7 +513,7 @@ libxlCapsInitGuests(libxl_ctx *ctx, virCapsPtr caps)
(guest_archs[i].hvm ?
LIBXL_FIRMWARE_DIR "/hvmloader" :
NULL),
- 1,
+ nmachines,
machines)) == NULL) {
virCapabilitiesFreeMachines(machines, 1);
return -1;
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list
