On Mon, Jun 22, 2020 at 03:54:58PM +0200, Philippe Mathieu-Daudé wrote:
> 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 <ler...@redhat.com>
> >> Signed-off-by: Philippe Mathieu-Daudé <phi...@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.
Or can possibly use the simpler g_byte_array_free and avoid the g_autoptr
Regards,
Daniel
--
|: https://berrange.com -o- https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o- https://fstop138.berrange.com :|
|: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
