On Fri, Sep 16, 2016 at 04:39:23PM -0600, Jim Fehlig wrote:
> On 08/05/2016 12:05 PM, 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>
> > ---
> > src/libxl/libxl_capabilities.c | 40 +++++++++++++++++++++++++++++++---------
> > src/libxl/libxl_conf.c | 2 ++
> > src/libxl/libxl_driver.c | 6 ++++--
> > 3 files changed, 37 insertions(+), 11 deletions(-)
>
> I didn't investigate, but this patch did not apply cleanly.
>
> Does 'xenpvh' need to be added to docs/schema/domaincommon.rng? The schema looks
> dated anyhow since it currently contains 'xenpv' and 'xenner'. And perhaps this
> value should be added to docs/formatdomain.html.in, along with a sentence about
> the possible values for Xen machines.
After further evaluation[1], PVHv1 is not the thing I wanted here. And
PVHv2 is going to be significantly different. While this patch do work
for me, I'm not going to spend more time on PVHv1.
> > diff --git a/src/libxl/libxl_capabilities.c b/src/libxl/libxl_capabilities.c
> > index 0145116..c443353 100644
> > --- a/src/libxl/libxl_capabilities.c
> > +++ b/src/libxl/libxl_capabilities.c
> > @@ -45,11 +45,16 @@ VIR_LOG_INIT("libxl.libxl_capabilities");
> > /* see xen-unstable.hg/xen/include/asm-x86/cpufeature.h */
> > #define LIBXL_X86_FEATURE_PAE_MASK 0x40
> >
> > +enum machine_type {
> > + machine_hvm,
> > + machine_pvh,
> > + machine_pv,
> > +};
> >
> > struct guest_arch {
> > virArch arch;
> > int bits;
> > - int hvm;
> > + enum machine_type machine;
> > int pae;
> > int nonpae;
> > int ia64_be;
> > @@ -296,7 +301,7 @@ libxlCapsInitGuests(libxl_ctx *ctx, virCapsPtr caps)
> > /* Search for existing matching (model,hvm) tuple */
> > for (i = 0; i < nr_guest_archs; i++) {
> > if ((guest_archs[i].arch == arch) &&
> > - guest_archs[i].hvm == hvm)
> > + guest_archs[i].machine == (hvm ? machine_hvm : machine_pv))
> > break;
> > }
> >
> > @@ -308,7 +313,7 @@ libxlCapsInitGuests(libxl_ctx *ctx, virCapsPtr caps)
> > nr_guest_archs++;
> >
> > guest_archs[i].arch = arch;
> > - guest_archs[i].hvm = hvm;
> > + guest_archs[i].machine = hvm ? machine_hvm : machine_pv;
> >
> > /* Careful not to overwrite a previous positive
> > setting with a negative one here - some archs
> > @@ -320,23 +325,40 @@ libxlCapsInitGuests(libxl_ctx *ctx, virCapsPtr caps)
> > guest_archs[i].nonpae = nonpae;
> > if (ia64_be)
> > guest_archs[i].ia64_be = ia64_be;
> > +
> > + /* On Xen >= 4.4 add PVH for each HVM guest, and do it only once */
> > + if ((ver_info->xen_version_major > 4 ||
> > + (ver_info->xen_version_major == 4 &&
> > + ver_info->xen_version_minor >= 4)) &&
> > + hvm && i == nr_guest_archs-1) {
> > + i = nr_guest_archs;
> > + /* Too many arch flavours - highly unlikely ! */
> > + if (i >= ARRAY_CARDINALITY(guest_archs))
> > + continue;
> > + nr_guest_archs++;
> > + guest_archs[i].arch = arch;
> > + guest_archs[i].machine = machine_pvh;
> > + }
> > }
> > }
> > 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].machine == machine_hvm ? "xenfv" :
> > + (guest_archs[i].machine == machine_pvh ? "xenpvh" : "xenpv")};
> > virCapsGuestMachinePtr *machines;
> >
> > if ((machines = virCapabilitiesAllocMachines(xen_machines, 1)) == NULL)
> > return -1;
> >
> > if ((guest = virCapabilitiesAddGuest(caps,
> > - guest_archs[i].hvm ? VIR_DOMAIN_OSTYPE_HVM : VIR_DOMAIN_OSTYPE_XEN,
> > + guest_archs[i].machine == machine_hvm ?
> > + VIR_DOMAIN_OSTYPE_HVM : VIR_DOMAIN_OSTYPE_XEN,
>
> Is a new VIR_DOMAIN_OSTYPE_XENPVH needed?
Not sure about this. Wouldn't that require adding `os.type ==
VIR_DOMAIN_OSTYPE_XEN || os.type == VIR_DOMAIN_OSTYPE_XENPVH` in a lot
of places? If actual settings are mostly the same, I don't see any
reason for introducing such value.
> > guest_archs[i].arch,
> > LIBXL_EXECBIN_DIR "/qemu-system-i386",
> > - (guest_archs[i].hvm ?
> > + (guest_archs[i].machine == machine_hvm ?
> > LIBXL_FIRMWARE_DIR "/hvmloader" :
> > NULL),
> > 1,
> > @@ -375,7 +397,7 @@ libxlCapsInitGuests(libxl_ctx *ctx, virCapsPtr caps)
> > 0) == NULL)
> > return -1;
> >
> > - if (guest_archs[i].hvm) {
> > + if (guest_archs[i].machine != machine_pv) {
> > if (virCapabilitiesAddGuestFeature(guest,
> > "acpi",
> > 1,
> > @@ -390,7 +412,7 @@ libxlCapsInitGuests(libxl_ctx *ctx, virCapsPtr caps)
> > if (virCapabilitiesAddGuestFeature(guest,
> > "hap",
> > 1,
> > - 1) == NULL)
> > + guest_archs[i].machine == machine_hvm) == NULL)
> > return -1;
> > }
> > }
> > @@ -409,7 +431,7 @@ libxlMakeDomainOSCaps(const char *machine,
> >
> > os->supported = true;
> >
> > - if (STREQ(machine, "xenpv"))
> > + if (STREQ(machine, "xenpv") || STREQ(machine, "xenpvh"))
> > return 0;
> >
> > capsLoader->supported = true;
> > diff --git a/src/libxl/libxl_conf.c b/src/libxl/libxl_conf.c
> > index 5202ca1..aa06586 100644
> > --- a/src/libxl/libxl_conf.c
> > +++ b/src/libxl/libxl_conf.c
> > @@ -173,6 +173,8 @@ libxlMakeDomCreateInfo(libxl_ctx *ctx,
> > }
> > } else {
> > c_info->type = LIBXL_DOMAIN_TYPE_PV;
> > + if (STREQ(def->os.machine, "xenpvh"))
> > + libxl_defbool_set(&c_info->pvh, true);
>
> I assume this won't change with HVMlite, aka pvh2?
It will, unfortunately. HVMlite is enabled by setting device model to
none.
> > }
> >
> > if (VIR_STRDUP(c_info->name, def->name) < 0)
> > diff --git a/src/libxl/libxl_driver.c b/src/libxl/libxl_driver.c
> > index 4957072..fa58346 100644
> > --- a/src/libxl/libxl_driver.c
> > +++ b/src/libxl/libxl_driver.c
> > @@ -6321,9 +6321,11 @@ libxlConnectGetDomainCapabilities(virConnectPtr conn,
> > emulatorbin = "/usr/bin/qemu-system-x86_64";
> >
> > if (machine) {
> > - if (STRNEQ(machine, "xenpv") && STRNEQ(machine, "xenfv")) {
> > + if (STRNEQ(machine, "xenpv") &&
> > + STRNEQ(machine, "xenpvh") &&
> > + STRNEQ(machine, "xenfv")) {
> > virReportError(VIR_ERR_INVALID_ARG, "%s",
> > - _("Xen only supports 'xenpv' and 'xenfv' machines"));
> > + _("Xen only supports 'xenpv', 'xenpvh' and 'xenfv' machines"));
> > goto cleanup;
> > }
> > } else {
>
> WRT domain capabilities, should pvh be treated like pv? I.e. do they both have
> the same max vcpus, etc?
Yes, PVH behave like PV. But PVHv2 like HVM.
> Also, supporting a new knob in the XML usually means supporting conversion of
> that knob to xl.cfg. Can you add domXML <-> xl.cfg conversion for pvh? And a
> test case for the conversion too please?
I'll add this for PVHv2...
[1] http://markmail.org/message/c7o7qsc3chkigdzv
--
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
Attachment:
signature.asc
Description: PGP signature
-- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list