Re: [PATCH v5 2/5] libxl: add query function for backend support by device model

[Juergen Gross <jgross@suse.com>]

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
>>
> 
> 


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel