| Message ID | 1453291044-83976-6-git-send-email-roger.pau@citrix.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
On Wed, 2016-01-20 at 12:57 +0100, Roger Pau Monne wrote: > Allow enabling or disabling emulated devices from the libxl domain > configuration file. For HVM guests with a device model all the emulated > devices are enabled. For HVM guests without a device model no devices are > enabled by default, although they can be enabled using the options > provided. > The arbiter of whether a combination is posible or not is always Xen, > libxl > doesn't do any kind of check. > > This set of options is also propagated inside of the libxl migration record > as part of the contents of the libxl_domain_build_info struct. ... and this is the real motivation for this change, not actually allowing users to control all this AIUI. Did you check that the fields updated using libxl_defbool_setdefault are actually updated in the JSON copy and therefore propagated to the other side of a migration as specific values and not as "pick a default"? I think we don't want these changing on migration. I think/hope all this was automatically handled by the work Wei did in the last release cycle. > Signed-off-by: Roger Pau Monné <roger.pau@citrix.com> > --- > Cc: Ian Jackson <ian.jackson@eu.citrix.com> > Cc: Ian Campbell <ian.campbell@citrix.com> > Cc: Wei Liu <wei.liu2@citrix.com> > --- > docs/man/xl.cfg.pod.5 | 39 +++++++++++++++++++++++++++++++++++++++ > tools/libxl/libxl.h | 11 +++++++++++ > tools/libxl/libxl_create.c | 21 ++++++++++++++++++++- > tools/libxl/libxl_types.idl | 6 ++++++ > tools/libxl/libxl_x86.c | 33 ++++++++++++++++++++++++++++----- > tools/libxl/xl_cmdimpl.c | 7 +++++++ > 6 files changed, 111 insertions(+), 6 deletions(-) > > diff --git a/docs/man/xl.cfg.pod.5 b/docs/man/xl.cfg.pod.5 > index 8899f75..46d4529 100644 > --- a/docs/man/xl.cfg.pod.5 > +++ b/docs/man/xl.cfg.pod.5 > @@ -1762,6 +1762,45 @@ See F<docs/misc/pci-device-reservations.txt> for > more information. > > =back > > +=head3 HVM without a device model options > + > +This options can be used to change the set of emulated devices provided "These..." > +to guests without a device model. Note that Xen might not support all > +possible combinations. By default HVM guests without a device model > +don't have any of them enabled. ... and for those with a device model? The title and text suggest these options are invalid/ignored in that case, but the code does actually honour what the user specified in this case. > diff --git a/tools/libxl/libxl_types.idl b/tools/libxl/libxl_types.idl > index 92c95e5..8a21cda 100644 > --- a/tools/libxl/libxl_types.idl > +++ b/tools/libxl/libxl_types.idl > @@ -519,6 +519,12 @@ libxl_domain_build_info = Struct("domain_build_info",[ > ("serial_list", libxl_string_list), > ("rdm", libxl_rdm_reserve), > ("rdm_mem_boundary_memkb", MemKB), > + ("lapic", libxl_defbool), > + ("ioapic", libxl_defbool), > + ("rtc", libxl_defbool), > + ("power_management", libxl_defbool), > + ("pic", libxl_defbool), > + ("pit", libxl_defbool), I wonder if these should go in a sub-struct. Although you might reasonably argue that this is already such a dumping ground it doesn't matter... > ])), > ("pv", Struct(None, [("kernel", string), > ("slack_memkb", MemKB), > diff --git a/tools/libxl/libxl_x86.c b/tools/libxl/libxl_x86.c > index 46cfafb..92f25fd 100644 > --- a/tools/libxl/libxl_x86.c > +++ b/tools/libxl/libxl_x86.c > @@ -7,15 +7,38 @@ int libxl__arch_domain_prepare_config(libxl__gc *gc, > libxl_domain_config *d_config, > xc_domain_configuration_t > *xc_config) > { > + struct libxl_domain_build_info *info = &d_config->b_info; > > - if (d_config->c_info.type == LIBXL_DOMAIN_TYPE_HVM && > - d_config->b_info.device_model_version != > - LIBXL_DEVICE_MODEL_VERSION_NONE) { > - /* HVM domains with a device model. */ So, I'm not 100% clear on why this check and the corresponding logic to set xc_config->emulation_flags is not also sufficient for after migration. Could you explain (and likely eventually add the rationale to the commit message). Ian.
El 20/01/16 a les 14.01, Ian Campbell ha escrit: > On Wed, 2016-01-20 at 12:57 +0100, Roger Pau Monne wrote: >> Allow enabling or disabling emulated devices from the libxl domain >> configuration file. For HVM guests with a device model all the emulated >> devices are enabled. For HVM guests without a device model no devices are >> enabled by default, although they can be enabled using the options >> provided. >> The arbiter of whether a combination is posible or not is always Xen, >> libxl >> doesn't do any kind of check. >> >> This set of options is also propagated inside of the libxl migration record >> as part of the contents of the libxl_domain_build_info struct. > > ... and this is the real motivation for this change, not actually allowing > users to control all this AIUI. > > Did you check that the fields updated using libxl_defbool_setdefault are > actually updated in the JSON copy and therefore propagated to the other > side of a migration as specific values and not as "pick a default"? I think > we don't want these changing on migration. I think/hope all this was > automatically handled by the work Wei did in the last release cycle. No, values populated by the {build/create}_info_setdefault functions are not propagated, OTOH values manually set by the user in the config file are indeed propagated. Do we have any guarantee that _setdefault is always going to behave in the same way? If we don't have that guarantee I think this is already a bug, and we should call _setdefault before sending the domain info to the other end. In fact I have a patch that does exactly that, but I'm unsure if it's needed because I don't know the policy regarding default values in libxl. >> Signed-off-by: Roger Pau Monné <roger.pau@citrix.com> >> --- >> Cc: Ian Jackson <ian.jackson@eu.citrix.com> >> Cc: Ian Campbell <ian.campbell@citrix.com> >> Cc: Wei Liu <wei.liu2@citrix.com> >> --- >> docs/man/xl.cfg.pod.5 | 39 +++++++++++++++++++++++++++++++++++++++ >> tools/libxl/libxl.h | 11 +++++++++++ >> tools/libxl/libxl_create.c | 21 ++++++++++++++++++++- >> tools/libxl/libxl_types.idl | 6 ++++++ >> tools/libxl/libxl_x86.c | 33 ++++++++++++++++++++++++++++----- >> tools/libxl/xl_cmdimpl.c | 7 +++++++ >> 6 files changed, 111 insertions(+), 6 deletions(-) >> >> diff --git a/docs/man/xl.cfg.pod.5 b/docs/man/xl.cfg.pod.5 >> index 8899f75..46d4529 100644 >> --- a/docs/man/xl.cfg.pod.5 >> +++ b/docs/man/xl.cfg.pod.5 >> @@ -1762,6 +1762,45 @@ See F<docs/misc/pci-device-reservations.txt> for >> more information. >> >> =back >> >> +=head3 HVM without a device model options >> + >> +This options can be used to change the set of emulated devices provided > > "These..." > >> +to guests without a device model. Note that Xen might not support all >> +possible combinations. By default HVM guests without a device model >> +don't have any of them enabled. > > ... and for those with a device model? The title and text suggest these > options are invalid/ignored in that case, but the code does actually honour > what the user specified in this case. Right, I've clarified this by adding the following paragraph: "It is important to notice that these options (except the hpet one) are not available to HVM guests with a device model, and trying to set them will cause xl to exit with an error." I've also fixed up the code in libxl__domain_build_info_setdefault to actually error out if a HVM guest with device model tries to set any of them. >> diff --git a/tools/libxl/libxl_types.idl b/tools/libxl/libxl_types.idl >> index 92c95e5..8a21cda 100644 >> --- a/tools/libxl/libxl_types.idl >> +++ b/tools/libxl/libxl_types.idl >> @@ -519,6 +519,12 @@ libxl_domain_build_info = Struct("domain_build_info",[ >> ("serial_list", libxl_string_list), >> ("rdm", libxl_rdm_reserve), >> ("rdm_mem_boundary_memkb", MemKB), >> + ("lapic", libxl_defbool), >> + ("ioapic", libxl_defbool), >> + ("rtc", libxl_defbool), >> + ("power_management", libxl_defbool), >> + ("pic", libxl_defbool), >> + ("pit", libxl_defbool), > > I wonder if these should go in a sub-struct. Although you might reasonably > argue that this is already such a dumping ground it doesn't matter... Right, TBH I saw that ARM added an arch_arm sub-struct, which sounds fine and should have been done earlier. Now the hvm sub-struct is already so x86 specific that, as you said, I don't think it matters much. >> ])), >> ("pv", Struct(None, [("kernel", string), >> ("slack_memkb", MemKB), >> diff --git a/tools/libxl/libxl_x86.c b/tools/libxl/libxl_x86.c >> index 46cfafb..92f25fd 100644 >> --- a/tools/libxl/libxl_x86.c >> +++ b/tools/libxl/libxl_x86.c >> @@ -7,15 +7,38 @@ int libxl__arch_domain_prepare_config(libxl__gc *gc, >> libxl_domain_config *d_config, >> xc_domain_configuration_t >> *xc_config) >> { >> + struct libxl_domain_build_info *info = &d_config->b_info; >> >> - if (d_config->c_info.type == LIBXL_DOMAIN_TYPE_HVM && >> - d_config->b_info.device_model_version != >> - LIBXL_DEVICE_MODEL_VERSION_NONE) { >> - /* HVM domains with a device model. */ > > So, I'm not 100% clear on why this check and the corresponding logic to set > xc_config->emulation_flags is not also sufficient for after migration. > Could you explain (and likely eventually add the rationale to the commit > message). As I understand this, we want to avoid having two different places where the policy (ie: the set of enabled devices) is enforced. With the current code, libxl basically limits the set of allowed masks to what it knows. After the change libxl just becomes a proxy for transmitting what the user has selected to Xen, and Xen either accepts or refuses it, basically making Xen the only arbiter that decides which emulated devices get enabled or not. This means that if we want to make more emulated devices available to the guest in the future no libxl changes will be required. It also means that HVMlite guests created with current Xen will be capable of migrating to newer version of Xen, that might have a different default policy. For example in the future we might want to enable the lapic by default, so if a guest is created with the current Xen version it doesn't get a lapic at all, and then when migrated to newer versions a lapic would magically appear after the migration, which is not desired. Roger.
On Wed, 2016-01-20 at 19:33 +0100, Roger Pau Monné wrote: > El 20/01/16 a les 14.01, Ian Campbell ha escrit: > > On Wed, 2016-01-20 at 12:57 +0100, Roger Pau Monne wrote: > > > Allow enabling or disabling emulated devices from the libxl domain > > > configuration file. For HVM guests with a device model all the > > > emulated > > > devices are enabled. For HVM guests without a device model no devices > > > are > > > enabled by default, although they can be enabled using the options > > > provided. > > > The arbiter of whether a combination is posible or not is always Xen, > > > libxl > > > doesn't do any kind of check. > > > > > > This set of options is also propagated inside of the libxl migration > > > record > > > as part of the contents of the libxl_domain_build_info struct. > > > > ... and this is the real motivation for this change, not actually > > allowing > > users to control all this AIUI. > > > > Did you check that the fields updated using libxl_defbool_setdefault > > are > > actually updated in the JSON copy and therefore propagated to the other > > side of a migration as specific values and not as "pick a default"? I > > think > > we don't want these changing on migration. I think/hope all this was > > automatically handled by the work Wei did in the last release cycle. > > No, values populated by the {build/create}_info_setdefault functions are > not propagated, OTOH values manually set by the user in the config file > are indeed propagated. Do we have any guarantee that _setdefault is > always going to behave in the same way? No, part of the purpose of defbool and the other "do the default" values is that we can evolve things over time. > If we don't have that guarantee I think this is already a bug, and we > should call _setdefault before sending the domain info to the other end. > In fact I have a patch that does exactly that, but I'm unsure if it's > needed because I don't know the policy regarding default values in libxl. Wei, isn't this (turning the defaults into concrete values) supposed to be taken care of by the JSON mangling which you added? > > > > Signed-off-by: Roger Pau Monné <roger.pau@citrix.com> > > > --- > > > Cc: Ian Jackson <ian.jackson@eu.citrix.com> > > > Cc: Ian Campbell <ian.campbell@citrix.com> > > > Cc: Wei Liu <wei.liu2@citrix.com> > > > --- > > > docs/man/xl.cfg.pod.5 | 39 > > > +++++++++++++++++++++++++++++++++++++++ > > > tools/libxl/libxl.h | 11 +++++++++++ > > > tools/libxl/libxl_create.c | 21 ++++++++++++++++++++- > > > tools/libxl/libxl_types.idl | 6 ++++++ > > > tools/libxl/libxl_x86.c | 33 ++++++++++++++++++++++++++++----- > > > tools/libxl/xl_cmdimpl.c | 7 +++++++ > > > 6 files changed, 111 insertions(+), 6 deletions(-) > > > > > > diff --git a/docs/man/xl.cfg.pod.5 b/docs/man/xl.cfg.pod.5 > > > index 8899f75..46d4529 100644 > > > --- a/docs/man/xl.cfg.pod.5 > > > +++ b/docs/man/xl.cfg.pod.5 > > > @@ -1762,6 +1762,45 @@ See F<docs/misc/pci-device-reservations.txt> > > > for > > > more information. > > > > > > =back > > > > > > +=head3 HVM without a device model options > > > + > > > +This options can be used to change the set of emulated devices > > > provided > > > > "These..." > > > > > +to guests without a device model. Note that Xen might not support > > > all > > > +possible combinations. By default HVM guests without a device model > > > +don't have any of them enabled. > > > > ... and for those with a device model? The title and text suggest these > > options are invalid/ignored in that case, but the code does actually > > honour > > what the user specified in this case. > > Right, I've clarified this by adding the following paragraph: > > "It is important to notice that these options (except the hpet one) are > not available to HVM guests with a device model, and trying to set them > will cause xl to exit with an error." > > I've also fixed up the code in libxl__domain_build_info_setdefault to > actually error out if a HVM guest with device model tries to set any of > them. > > > > diff --git a/tools/libxl/libxl_types.idl > > > b/tools/libxl/libxl_types.idl > > > index 92c95e5..8a21cda 100644 > > > --- a/tools/libxl/libxl_types.idl > > > +++ b/tools/libxl/libxl_types.idl > > > @@ -519,6 +519,12 @@ libxl_domain_build_info = > > > Struct("domain_build_info",[ > > > ("serial_list", libxl_st > > > ring_list), > > > ("rdm", libxl_rdm_reserve), > > > ("rdm_mem_boundary_memkb", > > > MemKB), > > > + ("lapic", libxl_de > > > fbool), > > > + ("ioapic", libxl_de > > > fbool), > > > + ("rtc", libxl_de > > > fbool), > > > + ("power_management", > > > libxl_defbool), > > > + ("pic", libxl_de > > > fbool), > > > + ("pit", libxl_de > > > fbool), > > > > I wonder if these should go in a sub-struct. Although you might > > reasonably > > argue that this is already such a dumping ground it doesn't matter... > > Right, TBH I saw that ARM added an arch_arm sub-struct, which sounds > fine and should have been done earlier. Now the hvm sub-struct is > already so x86 specific that, as you said, I don't think it matters much. I meant a substruct of hvm (i.e. vhm.emul_opts), but your point is also valid. > > > ])), > > > ("pv", Struct(None, [("kernel", string), > > > ("slack_memkb", MemKB), > > > diff --git a/tools/libxl/libxl_x86.c b/tools/libxl/libxl_x86.c > > > index 46cfafb..92f25fd 100644 > > > --- a/tools/libxl/libxl_x86.c > > > +++ b/tools/libxl/libxl_x86.c > > > @@ -7,15 +7,38 @@ int libxl__arch_domain_prepare_config(libxl__gc *gc, > > > libxl_domain_config *d_config, > > > xc_domain_configuration_t > > > *xc_config) > > > { > > > + struct libxl_domain_build_info *info = &d_config->b_info; > > > > > > - if (d_config->c_info.type == LIBXL_DOMAIN_TYPE_HVM && > > > - d_config->b_info.device_model_version != > > > - LIBXL_DEVICE_MODEL_VERSION_NONE) { > > > - /* HVM domains with a device model. */ > > > > So, I'm not 100% clear on why this check and the corresponding logic to set > > xc_config->emulation_flags is not also sufficient for after migration. > > Could you explain (and likely eventually add the rationale to the commit > > message). > > As I understand this, we want to avoid having two different places where > the policy (ie: the set of enabled devices) is enforced. But it must _always_ be enforced by Xen as the last resort. > With the current code, libxl basically limits the set of allowed masks > to what it knows. After the change libxl just becomes a proxy for > transmitting what the user has selected to Xen, and Xen either accepts > or refuses it, basically making Xen the only arbiter that decides which > emulated devices get enabled or not. This means that if we want to make > more emulated devices available to the guest in the future no libxl > changes will be required. We would need to add a new defbool for the new feature. > It also means that HVMlite guests created with current Xen will be > capable of migrating to newer version of Xen, that might have a > different default policy. For example in the future we might want to > enable the lapic by default, so if a guest is created with the current > Xen version it doesn't get a lapic at all, and then when migrated to > newer versions a lapic would magically appear after the migration, which > is not desired. ... and the reason these details can't be propagated via the Xen blob is that this emul stuff needs to be set exactly once at domain create time I suppose? Changing it to be later binding is considered to be too hard/too big a yak? Even with the set of devices set at domain creation time Xen needs to take care when reading its blob, and not fall apart (from a security PoV, it's allowed to fail the state load) when presented with a save record relating to something which is supposedly disabled. Has this been checked? Ian.
diff --git a/docs/man/xl.cfg.pod.5 b/docs/man/xl.cfg.pod.5 index 8899f75..46d4529 100644 --- a/docs/man/xl.cfg.pod.5 +++ b/docs/man/xl.cfg.pod.5 @@ -1762,6 +1762,45 @@ See F<docs/misc/pci-device-reservations.txt> for more information. =back +=head3 HVM without a device model options + +This options can be used to change the set of emulated devices provided +to guests without a device model. Note that Xen might not support all +possible combinations. By default HVM guests without a device model +don't have any of them enabled. + +=over 4 + +=item B<lapic=BOOLEAN> + +Enables or disables the Local APIC. + +=item B<ioapic=BOOLEAN> + +Enables or disables the IO APIC. + +=item B<rtc=BOOLEAN> + +Enables or disables the RTC. + +=item B<power_management=BOOLEAN> + +Enables or disables the ACPI power management timer and control interfaces. + +=item B<pic=BOOLEAN> + +Enables or disables the PIC. + +=item B<pit=BOOLEAN> + +Enables or disables the PIT. + +=item B<hpet=BOOLEAN> + +Enables or disables the HPET. + +=back + =head2 Device-Model Options The following options control the selection of the device-model. This diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h index 7114491..fc4ff1d 100644 --- a/tools/libxl/libxl.h +++ b/tools/libxl/libxl.h @@ -876,6 +876,17 @@ void libxl_mac_copy(libxl_ctx *ctx, libxl_mac *dst, libxl_mac *src); */ #define LIBXL_HAVE_DEVICE_MODEL_VERSION_NONE 1 +/* + * LIBXL_HAVE_EMULATED_DEVS_OPTIONS + * + * In the case that LIBXL_HAVE_EMULATED_DEVS_OPTIONS is set libxl + * allows enabling or disabling emulated devices for HVM guests + * without a device model. The following fields are added to the + * hvm structure inside of libxl_domain_build_info: lapic, ioapic, + * rtc, power_management, pic, pit. + */ +#define LIBXL_HAVE_EMULATED_DEVS_OPTIONS 1 + typedef char **libxl_string_list; void libxl_string_list_dispose(libxl_string_list *sl); int libxl_string_list_length(const libxl_string_list *sl); diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c index ba4c9e8..8a76a6b 100644 --- a/tools/libxl/libxl_create.c +++ b/tools/libxl/libxl_create.c @@ -295,13 +295,32 @@ int libxl__domain_build_info_setdefault(libxl__gc *gc, libxl_defbool_setdefault(&b_info->u.hvm.acpi_s4, true); libxl_defbool_setdefault(&b_info->u.hvm.nx, true); libxl_defbool_setdefault(&b_info->u.hvm.viridian, false); - libxl_defbool_setdefault(&b_info->u.hvm.hpet, true); libxl_defbool_setdefault(&b_info->u.hvm.vpt_align, true); libxl_defbool_setdefault(&b_info->u.hvm.nested_hvm, false); libxl_defbool_setdefault(&b_info->u.hvm.altp2m, false); libxl_defbool_setdefault(&b_info->u.hvm.usb, false); libxl_defbool_setdefault(&b_info->u.hvm.xen_platform_pci, true); + if (b_info->type == LIBXL_DOMAIN_TYPE_HVM && + b_info->device_model_version == LIBXL_DEVICE_MODEL_VERSION_NONE) + { + libxl_defbool_setdefault(&b_info->u.hvm.hpet, false); + libxl_defbool_setdefault(&b_info->u.hvm.lapic, false); + libxl_defbool_setdefault(&b_info->u.hvm.ioapic, false); + libxl_defbool_setdefault(&b_info->u.hvm.rtc, false); + libxl_defbool_setdefault(&b_info->u.hvm.power_management, false); + libxl_defbool_setdefault(&b_info->u.hvm.pic, false); + libxl_defbool_setdefault(&b_info->u.hvm.pit, false); + } else { + libxl_defbool_setdefault(&b_info->u.hvm.hpet, true); + libxl_defbool_setdefault(&b_info->u.hvm.lapic, true); + libxl_defbool_setdefault(&b_info->u.hvm.ioapic, true); + libxl_defbool_setdefault(&b_info->u.hvm.rtc, true); + libxl_defbool_setdefault(&b_info->u.hvm.power_management, true); + libxl_defbool_setdefault(&b_info->u.hvm.pic, true); + libxl_defbool_setdefault(&b_info->u.hvm.pit, true); + } + libxl_defbool_setdefault(&b_info->u.hvm.spice.enable, false); if (!libxl_defbool_val(b_info->u.hvm.spice.enable) && (b_info->u.hvm.spice.usbredirection > 0) ){ diff --git a/tools/libxl/libxl_types.idl b/tools/libxl/libxl_types.idl index 92c95e5..8a21cda 100644 --- a/tools/libxl/libxl_types.idl +++ b/tools/libxl/libxl_types.idl @@ -519,6 +519,12 @@ libxl_domain_build_info = Struct("domain_build_info",[ ("serial_list", libxl_string_list), ("rdm", libxl_rdm_reserve), ("rdm_mem_boundary_memkb", MemKB), + ("lapic", libxl_defbool), + ("ioapic", libxl_defbool), + ("rtc", libxl_defbool), + ("power_management", libxl_defbool), + ("pic", libxl_defbool), + ("pit", libxl_defbool), ])), ("pv", Struct(None, [("kernel", string), ("slack_memkb", MemKB), diff --git a/tools/libxl/libxl_x86.c b/tools/libxl/libxl_x86.c index 46cfafb..92f25fd 100644 --- a/tools/libxl/libxl_x86.c +++ b/tools/libxl/libxl_x86.c @@ -7,15 +7,38 @@ int libxl__arch_domain_prepare_config(libxl__gc *gc, libxl_domain_config *d_config, xc_domain_configuration_t *xc_config) { + struct libxl_domain_build_info *info = &d_config->b_info; - if (d_config->c_info.type == LIBXL_DOMAIN_TYPE_HVM && - d_config->b_info.device_model_version != - LIBXL_DEVICE_MODEL_VERSION_NONE) { - /* HVM domains with a device model. */ + if (d_config->c_info.type == LIBXL_DOMAIN_TYPE_PV) { + /* PV guests. */ + xc_config->emulation_flags = XEN_X86_EMU_PIT; + } else if (info->device_model_version != LIBXL_DEVICE_MODEL_VERSION_NONE) { + /* HVM guests with a device model. */ xc_config->emulation_flags = XEN_X86_EMU_ALL; } else { - /* PV or HVM domains without a device model. */ + /* HVM guests without a device model. */ xc_config->emulation_flags = 0; + + if (libxl_defbool_val(info->u.hvm.lapic)) + xc_config->emulation_flags |= XEN_X86_EMU_LAPIC; + if (libxl_defbool_val(info->u.hvm.ioapic)) + xc_config->emulation_flags |= XEN_X86_EMU_IOAPIC; + if (libxl_defbool_val(info->u.hvm.rtc)) + xc_config->emulation_flags |= XEN_X86_EMU_RTC; + if (libxl_defbool_val(info->u.hvm.power_management)) + xc_config->emulation_flags |= XEN_X86_EMU_PM; + if (libxl_defbool_val(info->u.hvm.pic)) + xc_config->emulation_flags |= XEN_X86_EMU_PIC; + if (libxl_defbool_val(info->u.hvm.pit)) + xc_config->emulation_flags |= XEN_X86_EMU_PIT; + if (libxl_defbool_val(info->u.hvm.hpet)) + xc_config->emulation_flags |= XEN_X86_EMU_HPET; + + if (info->u.hvm.vga.kind != LIBXL_VGA_INTERFACE_TYPE_NONE) + xc_config->emulation_flags |= XEN_X86_EMU_VGA; + + if (d_config->num_pcidevs != 0) + xc_config->emulation_flags |= XEN_X86_EMU_IOMMU; } return 0; diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c index 25507c7..3654097 100644 --- a/tools/libxl/xl_cmdimpl.c +++ b/tools/libxl/xl_cmdimpl.c @@ -1514,6 +1514,13 @@ static void parse_config_data(const char *config_source, xlu_cfg_get_defbool(config, "acpi_s4", &b_info->u.hvm.acpi_s4, 0); xlu_cfg_get_defbool(config, "nx", &b_info->u.hvm.nx, 0); xlu_cfg_get_defbool(config, "hpet", &b_info->u.hvm.hpet, 0); + xlu_cfg_get_defbool(config, "lapic", &b_info->u.hvm.lapic, 0); + xlu_cfg_get_defbool(config, "ioapic", &b_info->u.hvm.ioapic, 0); + xlu_cfg_get_defbool(config, "rtc", &b_info->u.hvm.rtc, 0); + xlu_cfg_get_defbool(config, "power_management", + &b_info->u.hvm.power_management, 0); + xlu_cfg_get_defbool(config, "pic", &b_info->u.hvm.pic, 0); + xlu_cfg_get_defbool(config, "pit", &b_info->u.hvm.pit, 0); xlu_cfg_get_defbool(config, "vpt_align", &b_info->u.hvm.vpt_align, 0); switch (xlu_cfg_get_list(config, "viridian",
Allow enabling or disabling emulated devices from the libxl domain configuration file. For HVM guests with a device model all the emulated devices are enabled. For HVM guests without a device model no devices are enabled by default, although they can be enabled using the options provided. The arbiter of whether a combination is posible or not is always Xen, libxl doesn't do any kind of check. This set of options is also propagated inside of the libxl migration record as part of the contents of the libxl_domain_build_info struct. Signed-off-by: Roger Pau Monné <roger.pau@citrix.com> --- Cc: Ian Jackson <ian.jackson@eu.citrix.com> Cc: Ian Campbell <ian.campbell@citrix.com> Cc: Wei Liu <wei.liu2@citrix.com> --- docs/man/xl.cfg.pod.5 | 39 +++++++++++++++++++++++++++++++++++++++ tools/libxl/libxl.h | 11 +++++++++++ tools/libxl/libxl_create.c | 21 ++++++++++++++++++++- tools/libxl/libxl_types.idl | 6 ++++++ tools/libxl/libxl_x86.c | 33 ++++++++++++++++++++++++++++----- tools/libxl/xl_cmdimpl.c | 7 +++++++ 6 files changed, 111 insertions(+), 6 deletions(-)