| Message ID | 1459339558-29183-3-git-send-email-jgross@suse.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
On 30/03/16 13:05, Juergen Gross wrote: > Add a function to query whether the device model is supporting a > specific backend type. The device model is writing the supported > backend types to Xenstore on startup. The new query function checks > for the appropriate entry to be present. > > As not all versions of qemu are capable to indicate support of > specific backends the query function is to be called with an indicator > whether the default return value should be "supported" (in case qemu > doesn't know set any support information) or "not supported". > > Signed-off-by: Juergen Gross <jgross@suse.com> Has this approach (writing backend capabilities into xenstore) been agreed on the qemu side? It's significantly different than what's been done so far wrt qemu feature discovery, right? I suppose we can just revert this whole series if they end up disagreeing with this approach, but I think that's something we'd like to avoid. (Although I suppose that's ultimately the release manager's call.) -George > --- > tools/libxl/libxl_dm.c | 19 +++++++++++++++++++ > tools/libxl/libxl_internal.h | 5 +++++ > 2 files changed, 24 insertions(+) > > diff --git a/tools/libxl/libxl_dm.c b/tools/libxl/libxl_dm.c > index 0d88c37..7d9abbe 100644 > --- a/tools/libxl/libxl_dm.c > +++ b/tools/libxl/libxl_dm.c > @@ -1920,6 +1920,25 @@ out: > device_model_spawn_outcome(egc, dmss, rc); > } > > +bool libxl__query_qemu_backend(libxl__gc *gc, uint32_t domid, > + uint32_t backend_id, const char *type, bool def) > +{ > + char *path; > + char **dir; > + unsigned int n; > + > + path = GCSPRINTF("%s/device-model/%u/backends", > + libxl__xs_get_dompath(gc, backend_id), domid); > + dir = libxl__xs_directory(gc, XBT_NULL, path, &n); > + if (!dir) > + return def; > + > + path = GCSPRINTF("%s/device-model/%u/backends/%s", > + libxl__xs_get_dompath(gc, backend_id), domid, type); > + dir = libxl__xs_directory(gc, XBT_NULL, path, &n); > + > + return !!dir; > +} > > static void device_model_confirm(libxl__egc *egc, libxl__spawn_state *spawn, > const char *xsdata) > diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h > index fc7bdab..c06ffc0 100644 > --- a/tools/libxl/libxl_internal.h > +++ b/tools/libxl/libxl_internal.h > @@ -1617,6 +1617,11 @@ _hidden const char *libxl__domain_device_model(libxl__gc *gc, > const libxl_domain_build_info *info); > _hidden int libxl__need_xenpv_qemu(libxl__gc *gc, > libxl_domain_config *d_config); > +_hidden bool libxl__query_qemu_backend(libxl__gc *gc, > + uint32_t domid, > + uint32_t backend_id, > + const char *type, > + bool def); > > /* > * This function will fix reserved device memory conflict >
On Wed, Mar 30, 2016 at 02:05:55PM +0200, Juergen Gross wrote: > Add a function to query whether the device model is supporting a > specific backend type. The device model is writing the supported > backend types to Xenstore on startup. The new query function checks > for the appropriate entry to be present. > > As not all versions of qemu are capable to indicate support of > specific backends the query function is to be called with an indicator > whether the default return value should be "supported" (in case qemu > doesn't know set any support information) or "not supported". > > Signed-off-by: Juergen Gross <jgross@suse.com> The code itself looks straightforward enough. But note that this is a new protocol that needs to be supported essentially forever. I've CC QEMU maintainers for their input. This also means even if we get this in for 4.7 we can't essentially benefit from it until this protocol is implemented in upstream QEMU. At this point I don't think I would take this particular patch for 4.7. (I haven't checked if the rest depends on this one though) Wei. > --- > tools/libxl/libxl_dm.c | 19 +++++++++++++++++++ > tools/libxl/libxl_internal.h | 5 +++++ > 2 files changed, 24 insertions(+) > > diff --git a/tools/libxl/libxl_dm.c b/tools/libxl/libxl_dm.c > index 0d88c37..7d9abbe 100644 > --- a/tools/libxl/libxl_dm.c > +++ b/tools/libxl/libxl_dm.c > @@ -1920,6 +1920,25 @@ out: > device_model_spawn_outcome(egc, dmss, rc); > } > > +bool libxl__query_qemu_backend(libxl__gc *gc, uint32_t domid, > + uint32_t backend_id, const char *type, bool def) > +{ > + char *path; > + char **dir; > + unsigned int n; > + > + path = GCSPRINTF("%s/device-model/%u/backends", > + libxl__xs_get_dompath(gc, backend_id), domid); > + dir = libxl__xs_directory(gc, XBT_NULL, path, &n); > + if (!dir) > + return def; > + > + path = GCSPRINTF("%s/device-model/%u/backends/%s", > + libxl__xs_get_dompath(gc, backend_id), domid, type); > + dir = libxl__xs_directory(gc, XBT_NULL, path, &n); > + > + return !!dir; > +} > > static void device_model_confirm(libxl__egc *egc, libxl__spawn_state *spawn, > const char *xsdata) > diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h > index fc7bdab..c06ffc0 100644 > --- a/tools/libxl/libxl_internal.h > +++ b/tools/libxl/libxl_internal.h > @@ -1617,6 +1617,11 @@ _hidden const char *libxl__domain_device_model(libxl__gc *gc, > const libxl_domain_build_info *info); > _hidden int libxl__need_xenpv_qemu(libxl__gc *gc, > libxl_domain_config *d_config); > +_hidden bool libxl__query_qemu_backend(libxl__gc *gc, > + uint32_t domid, > + uint32_t backend_id, > + const char *type, > + bool def); > > /* > * This function will fix reserved device memory conflict > -- > 2.6.2 >
On 30/03/16 15:44, George Dunlap wrote: > On 30/03/16 13:05, Juergen Gross wrote: >> Add a function to query whether the device model is supporting a >> specific backend type. The device model is writing the supported >> backend types to Xenstore on startup. The new query function checks >> for the appropriate entry to be present. >> >> As not all versions of qemu are capable to indicate support of >> specific backends the query function is to be called with an indicator >> whether the default return value should be "supported" (in case qemu >> doesn't know set any support information) or "not supported". >> >> Signed-off-by: Juergen Gross <jgross@suse.com> > > Has this approach (writing backend capabilities into xenstore) been > agreed on the qemu side? It's significantly different than what's been > done so far wrt qemu feature discovery, right? I wanted to make sure we agree on the approach. The qemu patch is trivial and I'll send it as soon as I've got the "go" on Xen side. The patch is just moving some functions to another source to be able to reuse those and it adds 4 lines of code. That's all. TBH: This is the natural way to do the feature discovery for Xen. It is simple and even today qemu is writing it's "running" state into Xenstore which is some kind of "feature" as well. And we can be sure that once qemu is started for a domain we'll have the features it is offering at a place where we can read them easily as often as we want. I don't think any other solution would just work for stubdom, driver domains etc. without adding special code for those cases. > I suppose we can just revert this whole series if they end up > disagreeing with this approach, but I think that's something we'd like > to avoid. (Although I suppose that's ultimately the release manager's > call.) Chicken and egg again. :-) Juergen > > -George > >> --- >> tools/libxl/libxl_dm.c | 19 +++++++++++++++++++ >> tools/libxl/libxl_internal.h | 5 +++++ >> 2 files changed, 24 insertions(+) >> >> diff --git a/tools/libxl/libxl_dm.c b/tools/libxl/libxl_dm.c >> index 0d88c37..7d9abbe 100644 >> --- a/tools/libxl/libxl_dm.c >> +++ b/tools/libxl/libxl_dm.c >> @@ -1920,6 +1920,25 @@ out: >> device_model_spawn_outcome(egc, dmss, rc); >> } >> >> +bool libxl__query_qemu_backend(libxl__gc *gc, uint32_t domid, >> + uint32_t backend_id, const char *type, bool def) >> +{ >> + char *path; >> + char **dir; >> + unsigned int n; >> + >> + path = GCSPRINTF("%s/device-model/%u/backends", >> + libxl__xs_get_dompath(gc, backend_id), domid); >> + dir = libxl__xs_directory(gc, XBT_NULL, path, &n); >> + if (!dir) >> + return def; >> + >> + path = GCSPRINTF("%s/device-model/%u/backends/%s", >> + libxl__xs_get_dompath(gc, backend_id), domid, type); >> + dir = libxl__xs_directory(gc, XBT_NULL, path, &n); >> + >> + return !!dir; >> +} >> >> static void device_model_confirm(libxl__egc *egc, libxl__spawn_state *spawn, >> const char *xsdata) >> diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h >> index fc7bdab..c06ffc0 100644 >> --- a/tools/libxl/libxl_internal.h >> +++ b/tools/libxl/libxl_internal.h >> @@ -1617,6 +1617,11 @@ _hidden const char *libxl__domain_device_model(libxl__gc *gc, >> const libxl_domain_build_info *info); >> _hidden int libxl__need_xenpv_qemu(libxl__gc *gc, >> libxl_domain_config *d_config); >> +_hidden bool libxl__query_qemu_backend(libxl__gc *gc, >> + uint32_t domid, >> + uint32_t backend_id, >> + const char *type, >> + bool def); >> >> /* >> * This function will fix reserved device memory conflict >> > >
On 30/03/16 15:53, Wei Liu wrote: > On Wed, Mar 30, 2016 at 02:05:55PM +0200, Juergen Gross wrote: >> Add a function to query whether the device model is supporting a >> specific backend type. The device model is writing the supported >> backend types to Xenstore on startup. The new query function checks >> for the appropriate entry to be present. >> >> As not all versions of qemu are capable to indicate support of >> specific backends the query function is to be called with an indicator >> whether the default return value should be "supported" (in case qemu >> doesn't know set any support information) or "not supported". >> >> Signed-off-by: Juergen Gross <jgross@suse.com> > > The code itself looks straightforward enough. > > But note that this is a new protocol that needs to be supported > essentially forever. I've CC QEMU maintainers for their input. Okay, I'll send the qemu patch now. > This also means even if we get this in for 4.7 we can't essentially > benefit from it until this protocol is implemented in upstream QEMU. At > this point I don't think I would take this particular patch for 4.7. > > (I haven't checked if the rest depends on this one though) George asked me to add some kind of feature test (qusb support by qemu). So I added it and yes, patch 3 depends on this one. Juergen > > Wei. > >> --- >> tools/libxl/libxl_dm.c | 19 +++++++++++++++++++ >> tools/libxl/libxl_internal.h | 5 +++++ >> 2 files changed, 24 insertions(+) >> >> diff --git a/tools/libxl/libxl_dm.c b/tools/libxl/libxl_dm.c >> index 0d88c37..7d9abbe 100644 >> --- a/tools/libxl/libxl_dm.c >> +++ b/tools/libxl/libxl_dm.c >> @@ -1920,6 +1920,25 @@ out: >> device_model_spawn_outcome(egc, dmss, rc); >> } >> >> +bool libxl__query_qemu_backend(libxl__gc *gc, uint32_t domid, >> + uint32_t backend_id, const char *type, bool def) >> +{ >> + char *path; >> + char **dir; >> + unsigned int n; >> + >> + path = GCSPRINTF("%s/device-model/%u/backends", >> + libxl__xs_get_dompath(gc, backend_id), domid); >> + dir = libxl__xs_directory(gc, XBT_NULL, path, &n); >> + if (!dir) >> + return def; >> + >> + path = GCSPRINTF("%s/device-model/%u/backends/%s", >> + libxl__xs_get_dompath(gc, backend_id), domid, type); >> + dir = libxl__xs_directory(gc, XBT_NULL, path, &n); >> + >> + return !!dir; >> +} >> >> static void device_model_confirm(libxl__egc *egc, libxl__spawn_state *spawn, >> const char *xsdata) >> diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h >> index fc7bdab..c06ffc0 100644 >> --- a/tools/libxl/libxl_internal.h >> +++ b/tools/libxl/libxl_internal.h >> @@ -1617,6 +1617,11 @@ _hidden const char *libxl__domain_device_model(libxl__gc *gc, >> const libxl_domain_build_info *info); >> _hidden int libxl__need_xenpv_qemu(libxl__gc *gc, >> libxl_domain_config *d_config); >> +_hidden bool libxl__query_qemu_backend(libxl__gc *gc, >> + uint32_t domid, >> + uint32_t backend_id, >> + const char *type, >> + bool def); >> >> /* >> * This function will fix reserved device memory conflict >> -- >> 2.6.2 >> >
On Wed, Mar 30, 2016 at 04:02:20PM +0200, Juergen Gross wrote: > On 30/03/16 15:53, Wei Liu wrote: > > On Wed, Mar 30, 2016 at 02:05:55PM +0200, Juergen Gross wrote: > >> Add a function to query whether the device model is supporting a > >> specific backend type. The device model is writing the supported > >> backend types to Xenstore on startup. The new query function checks > >> for the appropriate entry to be present. > >> > >> As not all versions of qemu are capable to indicate support of > >> specific backends the query function is to be called with an indicator > >> whether the default return value should be "supported" (in case qemu > >> doesn't know set any support information) or "not supported". > >> > >> Signed-off-by: Juergen Gross <jgross@suse.com> > > > > The code itself looks straightforward enough. > > > > But note that this is a new protocol that needs to be supported > > essentially forever. I've CC QEMU maintainers for their input. > > Okay, I'll send the qemu patch now. > And also a patch to docs/misc/xenstore-paths.markdown please. Wei.
On 30/03/16 14:53, Wei Liu wrote: > On Wed, Mar 30, 2016 at 02:05:55PM +0200, Juergen Gross wrote: >> Add a function to query whether the device model is supporting a >> specific backend type. The device model is writing the supported >> backend types to Xenstore on startup. The new query function checks >> for the appropriate entry to be present. >> >> As not all versions of qemu are capable to indicate support of >> specific backends the query function is to be called with an indicator >> whether the default return value should be "supported" (in case qemu >> doesn't know set any support information) or "not supported". >> >> Signed-off-by: Juergen Gross <jgross@suse.com> > > The code itself looks straightforward enough. > > But note that this is a new protocol that needs to be supported > essentially forever. I've CC QEMU maintainers for their input. FWIW, libxl only needs to support this forever if qemu ever actually provides it. If no version of qemu ever ships with this check, then we can't break anything by removing it. This is what I was saying in my other comment -- we could just check this in, and back out the whole series if the qemu side gets NACK'ed. Even if we release with this, there's no real harm done, as the qusb code will simply never be activated. > This also means even if we get this in for 4.7 we can't essentially > benefit from it until this protocol is implemented in upstream QEMU. At > this point I don't think I would take this particular patch for 4.7. qemu has a faster release cycle than us, right? If we have support in principle for this approach, people who want qusb support can always use a newer qemu release. OTOH, if we check this in then the qemu folks can either take this exact approach, or something completely incompatible -- they can't make minor modifications. -George
On 30/03/16 16:09, Wei Liu wrote: > On Wed, Mar 30, 2016 at 04:02:20PM +0200, Juergen Gross wrote: >> On 30/03/16 15:53, Wei Liu wrote: >>> On Wed, Mar 30, 2016 at 02:05:55PM +0200, Juergen Gross wrote: >>>> Add a function to query whether the device model is supporting a >>>> specific backend type. The device model is writing the supported >>>> backend types to Xenstore on startup. The new query function checks >>>> for the appropriate entry to be present. >>>> >>>> As not all versions of qemu are capable to indicate support of >>>> specific backends the query function is to be called with an indicator >>>> whether the default return value should be "supported" (in case qemu >>>> doesn't know set any support information) or "not supported". >>>> >>>> Signed-off-by: Juergen Gross <jgross@suse.com> >>> >>> The code itself looks straightforward enough. >>> >>> But note that this is a new protocol that needs to be supported >>> essentially forever. I've CC QEMU maintainers for their input. >> >> Okay, I'll send the qemu patch now. >> > > And also a patch to docs/misc/xenstore-paths.markdown please. Aah, sure. Juergen
On Wed, Mar 30, 2016 at 04:11:39PM +0200, Juergen Gross wrote: > On 30/03/16 16:09, Wei Liu wrote: > > On Wed, Mar 30, 2016 at 04:02:20PM +0200, Juergen Gross wrote: > >> On 30/03/16 15:53, Wei Liu wrote: > >>> On Wed, Mar 30, 2016 at 02:05:55PM +0200, Juergen Gross wrote: > >>>> Add a function to query whether the device model is supporting a > >>>> specific backend type. The device model is writing the supported > >>>> backend types to Xenstore on startup. The new query function checks > >>>> for the appropriate entry to be present. > >>>> > >>>> As not all versions of qemu are capable to indicate support of > >>>> specific backends the query function is to be called with an indicator > >>>> whether the default return value should be "supported" (in case qemu > >>>> doesn't know set any support information) or "not supported". > >>>> > >>>> Signed-off-by: Juergen Gross <jgross@suse.com> > >>> > >>> The code itself looks straightforward enough. > >>> > >>> But note that this is a new protocol that needs to be supported > >>> essentially forever. I've CC QEMU maintainers for their input. > >> > >> Okay, I'll send the qemu patch now. > >> > > > > And also a patch to docs/misc/xenstore-paths.markdown please. > > Aah, sure. > Actually wait, I think all QEMU nodes are either under documented or I looked at the wrong place. Anthony, how should we document the protocol between QEMU and toolstack? Did I look at the wrong place? Wei. > > Juergen >
On Wed, Mar 30, 2016 at 03:10:45PM +0100, George Dunlap wrote: > On 30/03/16 14:53, Wei Liu wrote: > > On Wed, Mar 30, 2016 at 02:05:55PM +0200, Juergen Gross wrote: > >> Add a function to query whether the device model is supporting a > >> specific backend type. The device model is writing the supported > >> backend types to Xenstore on startup. The new query function checks > >> for the appropriate entry to be present. > >> > >> As not all versions of qemu are capable to indicate support of > >> specific backends the query function is to be called with an indicator > >> whether the default return value should be "supported" (in case qemu > >> doesn't know set any support information) or "not supported". > >> > >> Signed-off-by: Juergen Gross <jgross@suse.com> > > > > The code itself looks straightforward enough. > > > > But note that this is a new protocol that needs to be supported > > essentially forever. I've CC QEMU maintainers for their input. > > FWIW, libxl only needs to support this forever if qemu ever actually > provides it. If no version of qemu ever ships with this check, then we > can't break anything by removing it. > That's true. But the code is actually not very relevant, I think the protocol shall be written down somewhere in a canonical document -- that's something that we can't easily revert -- unless we don't document it, then I'm not sure what state should this feature be in or how do we advertise it in our release note. Wei. > This is what I was saying in my other comment -- we could just check > this in, and back out the whole series if the qemu side gets NACK'ed. > Even if we release with this, there's no real harm done, as the qusb > code will simply never be activated. > > > This also means even if we get this in for 4.7 we can't essentially > > benefit from it until this protocol is implemented in upstream QEMU. At > > this point I don't think I would take this particular patch for 4.7. > > qemu has a faster release cycle than us, right? If we have support in > principle for this approach, people who want qusb support can always use > a newer qemu release. > > OTOH, if we check this in then the qemu folks can either take this exact > approach, or something completely incompatible -- they can't make minor > modifications. > > -George
On Wed, Mar 30, 2016 at 03:26:23PM +0100, Wei Liu wrote: > On Wed, Mar 30, 2016 at 04:11:39PM +0200, Juergen Gross wrote: > > On 30/03/16 16:09, Wei Liu wrote: > > > On Wed, Mar 30, 2016 at 04:02:20PM +0200, Juergen Gross wrote: > > >> On 30/03/16 15:53, Wei Liu wrote: > > >>> On Wed, Mar 30, 2016 at 02:05:55PM +0200, Juergen Gross wrote: > > >>>> Add a function to query whether the device model is supporting a > > >>>> specific backend type. The device model is writing the supported > > >>>> backend types to Xenstore on startup. The new query function checks > > >>>> for the appropriate entry to be present. > > >>>> > > >>>> As not all versions of qemu are capable to indicate support of > > >>>> specific backends the query function is to be called with an indicator > > >>>> whether the default return value should be "supported" (in case qemu > > >>>> doesn't know set any support information) or "not supported". > > >>>> > > >>>> Signed-off-by: Juergen Gross <jgross@suse.com> > > >>> > > >>> The code itself looks straightforward enough. > > >>> > > >>> But note that this is a new protocol that needs to be supported > > >>> essentially forever. I've CC QEMU maintainers for their input. > > >> > > >> Okay, I'll send the qemu patch now. > > >> > > > > > > And also a patch to docs/misc/xenstore-paths.markdown please. > > > > Aah, sure. > > > > Actually wait, I think all QEMU nodes are either under documented or I > looked at the wrong place. I don't think there is anything missing, in term of PV protocol, which go through xenstore. Is there a node in particular that you are thinking of? > Anthony, how should we document the protocol between QEMU and toolstack? > Did I look at the wrong place? I think xenstore-paths.markdown would be a good place to document this protocol.
On Wed, Mar 30, 2016 at 04:55:42PM +0100, Anthony PERARD wrote: > On Wed, Mar 30, 2016 at 03:26:23PM +0100, Wei Liu wrote: > > On Wed, Mar 30, 2016 at 04:11:39PM +0200, Juergen Gross wrote: > > > On 30/03/16 16:09, Wei Liu wrote: > > > > On Wed, Mar 30, 2016 at 04:02:20PM +0200, Juergen Gross wrote: > > > >> On 30/03/16 15:53, Wei Liu wrote: > > > >>> On Wed, Mar 30, 2016 at 02:05:55PM +0200, Juergen Gross wrote: > > > >>>> Add a function to query whether the device model is supporting a > > > >>>> specific backend type. The device model is writing the supported > > > >>>> backend types to Xenstore on startup. The new query function checks > > > >>>> for the appropriate entry to be present. > > > >>>> > > > >>>> As not all versions of qemu are capable to indicate support of > > > >>>> specific backends the query function is to be called with an indicator > > > >>>> whether the default return value should be "supported" (in case qemu > > > >>>> doesn't know set any support information) or "not supported". > > > >>>> > > > >>>> Signed-off-by: Juergen Gross <jgross@suse.com> > > > >>> > > > >>> The code itself looks straightforward enough. > > > >>> > > > >>> But note that this is a new protocol that needs to be supported > > > >>> essentially forever. I've CC QEMU maintainers for their input. > > > >> > > > >> Okay, I'll send the qemu patch now. > > > >> > > > > > > > > And also a patch to docs/misc/xenstore-paths.markdown please. > > > > > > Aah, sure. > > > > > > > Actually wait, I think all QEMU nodes are either under documented or I > > looked at the wrong place. > > I don't think there is anything missing, in term of PV protocol, which go > through xenstore. Is there a node in particular that you are thinking of? > The node for video ram? That's what I was looking for. Then I realised it was probably not documented but I wasn't very sure. > > Anthony, how should we document the protocol between QEMU and toolstack? > > Did I look at the wrong place? > > I think xenstore-paths.markdown would be a good place to document this > protocol. > > -- > Anthony PERARD
On Wed, Mar 30, 2016 at 04:59:22PM +0100, Wei Liu wrote: > On Wed, Mar 30, 2016 at 04:55:42PM +0100, Anthony PERARD wrote: > > On Wed, Mar 30, 2016 at 03:26:23PM +0100, Wei Liu wrote: > > > On Wed, Mar 30, 2016 at 04:11:39PM +0200, Juergen Gross wrote: > > > > On 30/03/16 16:09, Wei Liu wrote: > > > > > And also a patch to docs/misc/xenstore-paths.markdown please. > > > > > > > > Aah, sure. > > > > > > > > > > Actually wait, I think all QEMU nodes are either under documented or I > > > looked at the wrong place. > > > > I don't think there is anything missing, in term of PV protocol, which go > > through xenstore. Is there a node in particular that you are thinking of? > > > > The node for video ram? That's what I was looking for. Then I realised > it was probably not documented but I wasn't very sure. Yes, this seams to be missing from the documentation.
diff --git a/tools/libxl/libxl_dm.c b/tools/libxl/libxl_dm.c index 0d88c37..7d9abbe 100644 --- a/tools/libxl/libxl_dm.c +++ b/tools/libxl/libxl_dm.c @@ -1920,6 +1920,25 @@ out: device_model_spawn_outcome(egc, dmss, rc); } +bool libxl__query_qemu_backend(libxl__gc *gc, uint32_t domid, + uint32_t backend_id, const char *type, bool def) +{ + char *path; + char **dir; + unsigned int n; + + path = GCSPRINTF("%s/device-model/%u/backends", + libxl__xs_get_dompath(gc, backend_id), domid); + dir = libxl__xs_directory(gc, XBT_NULL, path, &n); + if (!dir) + return def; + + path = GCSPRINTF("%s/device-model/%u/backends/%s", + libxl__xs_get_dompath(gc, backend_id), domid, type); + dir = libxl__xs_directory(gc, XBT_NULL, path, &n); + + return !!dir; +} static void device_model_confirm(libxl__egc *egc, libxl__spawn_state *spawn, const char *xsdata) diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h index fc7bdab..c06ffc0 100644 --- a/tools/libxl/libxl_internal.h +++ b/tools/libxl/libxl_internal.h @@ -1617,6 +1617,11 @@ _hidden const char *libxl__domain_device_model(libxl__gc *gc, const libxl_domain_build_info *info); _hidden int libxl__need_xenpv_qemu(libxl__gc *gc, libxl_domain_config *d_config); +_hidden bool libxl__query_qemu_backend(libxl__gc *gc, + uint32_t domid, + uint32_t backend_id, + const char *type, + bool def); /* * This function will fix reserved device memory conflict
Add a function to query whether the device model is supporting a specific backend type. The device model is writing the supported backend types to Xenstore on startup. The new query function checks for the appropriate entry to be present. As not all versions of qemu are capable to indicate support of specific backends the query function is to be called with an indicator whether the default return value should be "supported" (in case qemu doesn't know set any support information) or "not supported". Signed-off-by: Juergen Gross <jgross@suse.com> --- tools/libxl/libxl_dm.c | 19 +++++++++++++++++++ tools/libxl/libxl_internal.h | 5 +++++ 2 files changed, 24 insertions(+)