Re: [PATCH v9 1/5] hw/nvram/fw_cfg: Add the FW_CFG_DATA_GENERATOR interface

[Philippe Mathieu-Daudé]

On 6/16/20 5:31 PM, Daniel P. Berrangé wrote:
> On Mon, Jun 15, 2020 at 12:34:53PM +0200, Philippe Mathieu-Daudé wrote:
>> The FW_CFG_DATA_GENERATOR allows any object to produce
>> blob of data consumable by the fw_cfg device.
>>
>> Reviewed-by: Laszlo Ersek <lersek@redhat.com>
>> Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com>
>> ---
>>  docs/specs/fw_cfg.txt     |  9 ++++++-
>>  include/hw/nvram/fw_cfg.h | 52 +++++++++++++++++++++++++++++++++++++++
>>  hw/nvram/fw_cfg.c         | 36 +++++++++++++++++++++++++++
>>  3 files changed, 96 insertions(+), 1 deletion(-)
>>
>> diff --git a/docs/specs/fw_cfg.txt b/docs/specs/fw_cfg.txt
>> index 8f1ebc66fa..bc16daa38a 100644
>> --- a/docs/specs/fw_cfg.txt
>> +++ b/docs/specs/fw_cfg.txt
>> @@ -219,7 +219,7 @@ To check the result, read the "control" field:
>>  
>>  = Externally Provided Items =
>>  
>> -As of v2.4, "file" fw_cfg items (i.e., items with selector keys above
>> +Since v2.4, "file" fw_cfg items (i.e., items with selector keys above
>>  FW_CFG_FILE_FIRST, and with a corresponding entry in the fw_cfg file
>>  directory structure) may be inserted via the QEMU command line, using
>>  the following syntax:
>> @@ -230,6 +230,13 @@ Or
>>  
>>      -fw_cfg [name=]<item_name>,string=<string>
>>  
>> +Since v5.1, QEMU allows some objects to generate fw_cfg-specific content,
>> +the content is then associated with a "file" item using the 'gen_id' option
>> +in the command line, using the following syntax:
>> +
>> +    -object <generator-type>,id=<generated_id>,[generator-specific-options] 
>> \
>> +    -fw_cfg [name=]<item_name>,gen_id=<generated_id>
>> +
>>  See QEMU man page for more documentation.
>>  
>>  Using item_name with plain ASCII characters only is recommended.
>> diff --git a/include/hw/nvram/fw_cfg.h b/include/hw/nvram/fw_cfg.h
>> index 25d9307018..ca69666847 100644
>> --- a/include/hw/nvram/fw_cfg.h
>> +++ b/include/hw/nvram/fw_cfg.h
>> @@ -9,11 +9,43 @@
>>  #define TYPE_FW_CFG     "fw_cfg"
>>  #define TYPE_FW_CFG_IO  "fw_cfg_io"
>>  #define TYPE_FW_CFG_MEM "fw_cfg_mem"
>> +#define TYPE_FW_CFG_DATA_GENERATOR_INTERFACE "fw_cfg-data-generator"
>>  
>>  #define FW_CFG(obj)     OBJECT_CHECK(FWCfgState,    (obj), TYPE_FW_CFG)
>>  #define FW_CFG_IO(obj)  OBJECT_CHECK(FWCfgIoState,  (obj), TYPE_FW_CFG_IO)
>>  #define FW_CFG_MEM(obj) OBJECT_CHECK(FWCfgMemState, (obj), TYPE_FW_CFG_MEM)
>>  
>> +#define FW_CFG_DATA_GENERATOR_CLASS(class) \
>> +    OBJECT_CLASS_CHECK(FWCfgDataGeneratorClass, (class), \
>> +                       TYPE_FW_CFG_DATA_GENERATOR_INTERFACE)
>> +#define FW_CFG_DATA_GENERATOR_GET_CLASS(obj) \
>> +    OBJECT_GET_CLASS(FWCfgDataGeneratorClass, (obj), \
>> +                     TYPE_FW_CFG_DATA_GENERATOR_INTERFACE)
>> +
>> +typedef struct FWCfgDataGeneratorClass {
>> +    /*< private >*/
>> +    InterfaceClass parent_class;
>> +    /*< public >*/
>> +
>> +    /**
>> +     * get_data:
>> +     * @obj: the object implementing this interface
>> +     *
>> +     * Returns: pointer to start of the generated item data
>> +     *
>> +     * The returned pointer is a QObject weak reference, @obj owns
>> +     * the reference and may free it at any time in the future.
> 
> This description is a bit odd. We're just returning a plain byte
> array pointer, not a QObject, nor a reference, not will it be
> free'd at any time.
> 
>> +     */
>> +    const void *(*get_data)(Object *obj);
>> +    /**
>> +     * get_length:
>> +     * @obj: the object implementing this interface
>> +     *
>> +     * Returns: the size of the generated item data in bytes
>> +     */
>> +    size_t (*get_length)(Object *obj);
> 
> I'd be inclined to have a single method that returns a GByteArray,
> instead of separate methods for data & length.
> 
> That gives you a sized byte array, with a well define lifetime,
> which is what the caller really wants here. ie
> 
>     /**
>       * get_data:
>       * @obj: the object implementing this interface
>       *
>       * Returns: reference to a byte array containing the data.
>       * The caller should release the reference when no longer
>       * required.
>       */
>      GByteArray *(*get_data)(Object *obj);
> 
>> +} FWCfgDataGeneratorClass;
>> +
> 
> ....
> 
> 
>> +size_t fw_cfg_add_from_generator(FWCfgState *s, const char *filename,
>> +                                 const char *gen_id, Error **errp)
>> +{
>> +    FWCfgDataGeneratorClass *klass;
>> +    Object *obj;
>> +    size_t size;
>> +
>> +    obj = object_resolve_path_component(object_get_objects_root(), gen_id);
>> +    if (!obj) {
>> +        error_setg(errp, "Cannot find object ID '%s'", gen_id);
>> +        return 0;
>> +    }
>> +    if (!object_dynamic_cast(obj, TYPE_FW_CFG_DATA_GENERATOR_INTERFACE)) {
>> +        error_setg(errp, "Object ID '%s' is not a '%s' subclass",
>> +                   gen_id, TYPE_FW_CFG_DATA_GENERATOR_INTERFACE);
>> +        return 0;
>> +    }
>> +    klass = FW_CFG_DATA_GENERATOR_GET_CLASS(obj);
> 
> ...then the following:
> 
>> +    size = klass->get_length(obj);
>> +    if (size == 0) {
>> +        error_setg(errp, "Object ID '%s' failed to generate fw_cfg data",
>> +                   gen_id);
>> +        return 0;
>> +    }
>> +    fw_cfg_add_file(s, filename, g_memdup(klass->get_data(obj), 
>> (guint)size),
>> +                    size);
> 
> Can be replaced with:
> 
>    g_autoptr(GByteArray) data = klass->get_data(obj);
> 
>    fw_cfg_add_file(s, filename, g_byte_array_steal(data, NULL),
>                    (guint)g_byte_array_get_size(data));

g_byte_array_steal() has been added in GLib 2.64,
QEMU supports up to 2.48.

I guess I have to use g_byte_array_free_to_bytes()
and g_memdup(g_bytes_get_data()) to achieve something
similar. I'll try.

> 
> 
> If there's a real possibility of failure, then an 'Error **errp' should
> be added  to the 'get_data' method, so this code doesn't have to invent
> a error message with no useful info on the real failure.
> 
>> +
>> +    return size;
>> +}
>> +
> 
> Regards,
> Daniel
>