Marek Marczykowski-Górecki wrote: > Xen have feature of having device model in separate domain (called stub > domain). Add <stubdomain> element to allow selecting such configuration. > Emulator path is still used for qemu running in dom0 (if any). Libxl currently > do not allow to select stubdomain path. > > Signed-off-by: Marek Marczykowski-Górecki <marmarek@xxxxxxxxxxxxxxxxxxxxxx> > --- > docs/formatdomain.html.in | 13 +++++++++++++ > docs/schemas/domaincommon.rng | 10 ++++++++++ > src/conf/domain_conf.c | 14 ++++++++++++++ > src/conf/domain_conf.h | 3 ++- > src/libxl/libxl_conf.c | 8 ++++++++ > 5 files changed, 47 insertions(+), 1 deletion(-) > > Changes in v4: > - change <emulator type='stubdom'> to separate <stubdomain> element > > diff --git a/docs/formatdomain.html.in b/docs/formatdomain.html.in > index fb0a0d1..054f48f 100644 > --- a/docs/formatdomain.html.in > +++ b/docs/formatdomain.html.in > @@ -1670,6 +1670,19 @@ > </dd> > </dl> > > + <dl> > + <dt><code>stubdomain</code></dt> > + <dd> > + <span class="since">Since 1.2.13</span>, the optional <code>stubdomain</code> > + element contains <code>enabled</code> yes/no/default attribute. If enabled > + Emulator will be launched in stub domain (Xen only). Currently there > + is no way to provide path to that emulator. Note that in most cases > > + this emulator will be in addition to one in dom0. Why does a stubdomain need an emulator (running in dom0) to serve as a backend? Wouldn't it be better to give the stubdomain direct access to the resources it needs? Otherwise, It seems to defeat stubdomain's purpose of moving the emulator execution out of dom0. At least the Xen wiki describes this as primary motivation for studomains http://wiki.xen.org/wiki/Device_Model_Stub_Domains > + <code>emulator</code> element described above still controls the path > + to the dom0 instance. > + </dd> > + </dl> > > + I think it would be good to add an example above the description. E.g. along the lines of Daniel's previous example <devices> <emulator>/usr/lib/xen/bin/qemu-system-i386</emulator> <stubdomain enabled="yes|no"/> </devices> Regards, Jim > <h4><a name="elementsDisks">Hard drives, floppy disks, CDROMs</a></h4> > > <p> > diff --git a/docs/schemas/domaincommon.rng b/docs/schemas/domaincommon.rng > index 4e4fe9f..539db39 100644 > --- a/docs/schemas/domaincommon.rng > +++ b/docs/schemas/domaincommon.rng > @@ -2567,6 +2567,13 @@ > <ref name="absFilePath"/> > </element> > </define> > + <define name="stubdomain"> > + <element name="stubdomain"> > + <attribute name="enabled"> > + <ref name="virYesNo"/> > + </attribute> > + </element> > + </define> > <!-- > A graphic description, currently in Xen only 2 types are supported: > - sdl with optional display, xauth and fullscreen > @@ -4007,6 +4014,9 @@ > <optional> > <ref name="emulator"/> > </optional> > + <optional> > + <ref name="stubdomain"/> > + </optional> > <zeroOrMore> > <choice> > <ref name="disk"/> > diff --git a/src/conf/domain_conf.c b/src/conf/domain_conf.c > index c430e03..e327e55 100644 > --- a/src/conf/domain_conf.c > +++ b/src/conf/domain_conf.c > @@ -14107,6 +14107,9 @@ virDomainDefParseXML(xmlDocPtr xml, > } > > def->emulator = virXPathString("string(./devices/emulator[1])", ctxt); > + tmp = virXPathString("string(./devices/stubdomain/@enabled)", ctxt); > + if (tmp) > + def->stubdomain = virTristateBoolTypeFromString(tmp); > > /* analysis of the disk devices */ > if ((n = virXPathNodeSet("./devices/disk", ctxt, &nodes)) < 0) > @@ -16064,6 +16067,14 @@ virDomainDefCheckABIStability(virDomainDefPtr src, > goto error; > } > > + if (src->stubdomain != dst->stubdomain) { > + virReportError(VIR_ERR_CONFIG_UNSUPPORTED, > + _("Target domain stubdomain '%s' does not match source '%s'"), > + virTristateBoolTypeToString(dst->stubdomain), > + virTristateBoolTypeToString(src->stubdomain)); > + goto error; > + } > + > if (!virDomainDefFeaturesCheckABIStability(src, dst)) > goto error; > > @@ -20303,6 +20314,9 @@ virDomainDefFormatInternal(virDomainDefPtr def, > > virBufferEscapeString(buf, "<emulator>%s</emulator>\n", > def->emulator); > + if (def->stubdomain) > + virBufferAsprintf(buf, "<stubdomain enabled='%s'/>\n", > + virTristateBoolTypeToString(def->stubdomain)); > > for (n = 0; n < def->ndisks; n++) > if (virDomainDiskDefFormat(buf, def->disks[n], flags) < 0) > diff --git a/src/conf/domain_conf.h b/src/conf/domain_conf.h > index 36c8131..446f4f0 100644 > --- a/src/conf/domain_conf.h > +++ b/src/conf/domain_conf.h > @@ -2108,9 +2108,10 @@ struct _virDomainDef { > > virDomainOSDef os; > char *emulator; > - /* These three options are of type virTristateSwitch, > + /* These four options are of type virTristateSwitch, > * except VIR_DOMAIN_FEATURE_CAPABILITIES that is of type > * virDomainCapabilitiesPolicy */ > + int stubdomain; > int features[VIR_DOMAIN_FEATURE_LAST]; > int apic_eoi; > int hyperv_features[VIR_DOMAIN_HYPERV_LAST]; > diff --git a/src/libxl/libxl_conf.c b/src/libxl/libxl_conf.c > index 50ef9d8..8ec3c75 100644 > --- a/src/libxl/libxl_conf.c > +++ b/src/libxl/libxl_conf.c > @@ -727,6 +727,14 @@ libxlMakeDomBuildInfo(virDomainDefPtr def, > b_info->device_model_version = libxlDomainGetEmulatorType(def); > } > > + /* In case of stubdom there will be two qemu instances: > + * - in stubdom (libxl uses hardcoded path for this one), > + * - in dom0 as a backend for stubdom (if needed). > + */ > + if (def->stubdomain) > + libxl_defbool_set(&b_info->device_model_stubdomain, > + def->stubdomain == VIR_TRISTATE_BOOL_YES); > + > if (def->nserials) { > if (def->nserials > 1) { > virReportError(VIR_ERR_CONFIG_UNSUPPORTED, > -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list