| Message ID | 1457622051-30189-3-git-send-email-jgross@suse.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
On Thu, Mar 10, 2016 at 3:00 PM, Juergen Gross <jgross@suse.com> wrote: > Today the device model (qemu) is started for a pv domain only in case > a device requiring qemu is specified in the domain configuration > (qdisk, vfb, channel). If there is no such device the device model > isn't started and hence it is possible to add such a device to the > domain later. > > Add a domain configuration parameter to specify the device model is > to be started in any case. This will enable adding devices with a > qemu based backend later. > > While the optimal solution would be to start the device model > automatically when needed this would require some major rework of > libxl at multiple places. > > Signed-off-by: Juergen Gross <jgross@suse.com> So wait -- what happens now if you try to attach a disk with a qdisk backend to a PV guest that didn't start with qemu running? I'd really like to see patch 3 get in, but I'm not really in favor of this sort of a user-visible hack, particularly as we have to support it in libxl more or less indefinitely. -George
On 17/03/16 17:06, George Dunlap wrote: > On Thu, Mar 10, 2016 at 3:00 PM, Juergen Gross <jgross@suse.com> wrote: >> Today the device model (qemu) is started for a pv domain only in case >> a device requiring qemu is specified in the domain configuration >> (qdisk, vfb, channel). If there is no such device the device model >> isn't started and hence it is possible to add such a device to the >> domain later. >> >> Add a domain configuration parameter to specify the device model is >> to be started in any case. This will enable adding devices with a >> qemu based backend later. >> >> While the optimal solution would be to start the device model >> automatically when needed this would require some major rework of >> libxl at multiple places. >> >> Signed-off-by: Juergen Gross <jgross@suse.com> > > So wait -- what happens now if you try to attach a disk with a qdisk > backend to a PV guest that didn't start with qemu running? It won't work (that was my test case for the patch). > I'd really like to see patch 3 get in, but I'm not really in favor of > this sort of a user-visible hack, particularly as we have to support > it in libxl more or less indefinitely. Hmm, really? We can add a smarter variant later which will start the device model in case it isn't started yet. Then the new config parameter could be just ignored. I didn't do the smart variant as I'm not sure I could set it up in time for 4.7. I'd be happy to do it with some assistance regarding the async framework of libxl I'm not at all familiar with. Juergen
On 18/03/16 08:11, Juergen Gross wrote: > On 17/03/16 17:06, George Dunlap wrote: >> On Thu, Mar 10, 2016 at 3:00 PM, Juergen Gross <jgross@suse.com> wrote: >>> Today the device model (qemu) is started for a pv domain only in case >>> a device requiring qemu is specified in the domain configuration >>> (qdisk, vfb, channel). If there is no such device the device model >>> isn't started and hence it is possible to add such a device to the >>> domain later. >>> >>> Add a domain configuration parameter to specify the device model is >>> to be started in any case. This will enable adding devices with a >>> qemu based backend later. >>> >>> While the optimal solution would be to start the device model >>> automatically when needed this would require some major rework of >>> libxl at multiple places. >>> >>> Signed-off-by: Juergen Gross <jgross@suse.com> >> >> So wait -- what happens now if you try to attach a disk with a qdisk >> backend to a PV guest that didn't start with qemu running? > > It won't work (that was my test case for the patch). > >> I'd really like to see patch 3 get in, but I'm not really in favor of >> this sort of a user-visible hack, particularly as we have to support >> it in libxl more or less indefinitely. > > Hmm, really? We can add a smarter variant later which will start the > device model in case it isn't started yet. Then the new config parameter > could be just ignored. Sure; but it will (probably) only actually be useful for one release cycle (now 6 months), and then it will sit around cluttering up the interface for years to come. The situation wrt hotplug has been this way for years now, and nobody has complained; I don't think an extra 6 months will be a big deal. Ultimately it's the tools maintainers' call; I wouldn't argue against it if one of them think it's a good idea. > I didn't do the smart variant as I'm not sure I could set it up in time > for 4.7. I'd be happy to do it with some assistance regarding the async > framework of libxl I'm not at all familiar with. I'm sure help could be arranged; but it might be difficult to do by 4.7. -George
On 21/03/16 15:28, George Dunlap wrote: > On 18/03/16 08:11, Juergen Gross wrote: >> On 17/03/16 17:06, George Dunlap wrote: >>> On Thu, Mar 10, 2016 at 3:00 PM, Juergen Gross <jgross@suse.com> wrote: >>>> Today the device model (qemu) is started for a pv domain only in case >>>> a device requiring qemu is specified in the domain configuration >>>> (qdisk, vfb, channel). If there is no such device the device model >>>> isn't started and hence it is possible to add such a device to the >>>> domain later. >>>> >>>> Add a domain configuration parameter to specify the device model is >>>> to be started in any case. This will enable adding devices with a >>>> qemu based backend later. >>>> >>>> While the optimal solution would be to start the device model >>>> automatically when needed this would require some major rework of >>>> libxl at multiple places. >>>> >>>> Signed-off-by: Juergen Gross <jgross@suse.com> >>> >>> So wait -- what happens now if you try to attach a disk with a qdisk >>> backend to a PV guest that didn't start with qemu running? >> >> It won't work (that was my test case for the patch). >> >>> I'd really like to see patch 3 get in, but I'm not really in favor of >>> this sort of a user-visible hack, particularly as we have to support >>> it in libxl more or less indefinitely. >> >> Hmm, really? We can add a smarter variant later which will start the >> device model in case it isn't started yet. Then the new config parameter >> could be just ignored. > > Sure; but it will (probably) only actually be useful for one release > cycle (now 6 months), and then it will sit around cluttering up the > interface for years to come. The situation wrt hotplug has been this > way for years now, and nobody has complained; I don't think an extra 6 > months will be a big deal. > > Ultimately it's the tools maintainers' call; I wouldn't argue against it > if one of them think it's a good idea. > >> I didn't do the smart variant as I'm not sure I could set it up in time >> for 4.7. I'd be happy to do it with some assistance regarding the async >> framework of libxl I'm not at all familiar with. > > I'm sure help could be arranged; but it might be difficult to do by 4.7. Okay, let's see what can be arranged. BTW: This patch is not strictly required for patch 3. Patch 3 is just adding another case where no device model is available when needed. Juergen
diff --git a/docs/man/xl.cfg.pod.5 b/docs/man/xl.cfg.pod.5 index b156caa..1dde66b 100644 --- a/docs/man/xl.cfg.pod.5 +++ b/docs/man/xl.cfg.pod.5 @@ -1939,6 +1939,12 @@ xen-qemudepriv-domid$domid or xen-qemudepriv-shared or root. Please note that running QEMU as non-root causes migration and PCI passthrough not to work properly. +=item B<device_model_always=BOOLEAN> + +If true, start the device model for paravirtualized domains even if this isn't +required according to the configured devices. This allows to add such devices +later when the domain is already running. + =back =head2 Keymaps diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c index 0e2b0a0..52a0a2f 100644 --- a/tools/libxl/libxl_create.c +++ b/tools/libxl/libxl_create.c @@ -73,6 +73,7 @@ int libxl__domain_build_info_setdefault(libxl__gc *gc, return ERROR_INVAL; } + libxl_defbool_setdefault(&b_info->device_model_always, false); libxl_defbool_setdefault(&b_info->device_model_stubdomain, false); if (libxl_defbool_val(b_info->device_model_stubdomain) && diff --git a/tools/libxl/libxl_dm.c b/tools/libxl/libxl_dm.c index 4b840f4..637b11d 100644 --- a/tools/libxl/libxl_dm.c +++ b/tools/libxl/libxl_dm.c @@ -2115,6 +2115,11 @@ int libxl__need_xenpv_qemu(libxl__gc *gc, libxl_domain_config *d_config) ret = libxl__get_domid(gc, &domid); if (ret) goto out; + if (libxl_defbool_val(d_config->b_info.device_model_always)) { + ret = 1; + goto out; + } + if (d_config->num_vfbs > 0) { ret = 1; goto out; diff --git a/tools/libxl/libxl_types.idl b/tools/libxl/libxl_types.idl index 2a99eeb..b0a9776 100644 --- a/tools/libxl/libxl_types.idl +++ b/tools/libxl/libxl_types.idl @@ -450,6 +450,7 @@ libxl_domain_build_info = Struct("domain_build_info",[ ("device_model_ssidref", uint32), ("device_model_ssid_label", string), ("device_model_user", string), + ("device_model_always", libxl_defbool), # extra parameters pass directly to qemu, NULL terminated ("extra", libxl_string_list), diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c index a3610fc..0fdca73 100644 --- a/tools/libxl/xl_cmdimpl.c +++ b/tools/libxl/xl_cmdimpl.c @@ -2269,6 +2269,9 @@ skip_usbdev: } /* parse device model arguments, this works for pv, hvm and stubdom */ + xlu_cfg_get_defbool (config, "device_model_always", + &b_info->device_model_always, 0); + if (!xlu_cfg_get_string (config, "device_model", &buf, 0)) { fprintf(stderr, "WARNING: ignoring device_model directive.\n"
Today the device model (qemu) is started for a pv domain only in case a device requiring qemu is specified in the domain configuration (qdisk, vfb, channel). If there is no such device the device model isn't started and hence it is possible to add such a device to the domain later. Add a domain configuration parameter to specify the device model is to be started in any case. This will enable adding devices with a qemu based backend later. While the optimal solution would be to start the device model automatically when needed this would require some major rework of libxl at multiple places. Signed-off-by: Juergen Gross <jgross@suse.com> --- docs/man/xl.cfg.pod.5 | 6 ++++++ tools/libxl/libxl_create.c | 1 + tools/libxl/libxl_dm.c | 5 +++++ tools/libxl/libxl_types.idl | 1 + tools/libxl/xl_cmdimpl.c | 3 +++ 5 files changed, 16 insertions(+)