From: "Daniel P. Berrangé" <berrange@redhat.com>
To: "Philippe Mathieu-Daudé" <philmd@redhat.com>
Cc: Paolo Bonzini <pbonzini@redhat.com>,
Laszlo Ersek <lersek@redhat.com>,
qemu-devel@nongnu.org, Gerd Hoffmann <kraxel@redhat.com>
Subject: Re: [PATCH v9 1/5] hw/nvram/fw_cfg: Add the FW_CFG_DATA_GENERATOR interface
Date: Mon, 22 Jun 2020 15:08:14 +0100 [thread overview]
Message-ID: <20200622140814.GI736373@redhat.com> (raw)
In-Reply-To: <f7c32845-3125-d7c4-0cb8-90ec45f6c135@redhat.com>
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 <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.
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 :|
next prev parent reply other threads:[~2020-06-22 14:11 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-06-15 10:34 [PATCH v9 0/5] fw_cfg: Add FW_CFG_DATA_GENERATOR; crypto: Add tls-cipher-suites Philippe Mathieu-Daudé
2020-06-15 10:34 ` [PATCH v9 1/5] hw/nvram/fw_cfg: Add the FW_CFG_DATA_GENERATOR interface Philippe Mathieu-Daudé
2020-06-16 15:31 ` Daniel P. Berrangé
2020-06-20 17:52 ` Richard Henderson
2020-06-22 13:54 ` Philippe Mathieu-Daudé
2020-06-22 14:08 ` Daniel P. Berrangé [this message]
2020-06-15 10:34 ` [PATCH v9 2/5] softmmu/vl: Let -fw_cfg option take a 'gen_id' argument Philippe Mathieu-Daudé
2020-06-15 10:34 ` [PATCH v9 3/5] softmmu/vl: Allow -fw_cfg 'gen_id' option to use the 'etc/' namespace Philippe Mathieu-Daudé
2020-06-15 10:34 ` [PATCH v9 4/5] crypto: Add tls-cipher-suites object Philippe Mathieu-Daudé
2020-06-16 16:32 ` Daniel P. Berrangé
2020-06-15 10:34 ` [PATCH v9 5/5] crypto/tls-cipher-suites: Produce fw_cfg consumable blob Philippe Mathieu-Daudé
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20200622140814.GI736373@redhat.com \
--to=berrange@redhat.com \
--cc=kraxel@redhat.com \
--cc=lersek@redhat.com \
--cc=pbonzini@redhat.com \
--cc=philmd@redhat.com \
--cc=qemu-devel@nongnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.