The 'blob_id' argument refers to a QOM object able to produce
data consumable by the fw_cfg device. The producer object must
implement the FW_CFG_DATA_GENERATOR interface.

Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com>
---
 softmmu/vl.c | 17 +++++++++++++----
 1 file changed, 13 insertions(+), 4 deletions(-)

diff --git a/softmmu/vl.c b/softmmu/vl.c
index ae5451bc23..f76c53ad2e 100644
--- a/softmmu/vl.c
+++ b/softmmu/vl.c
@@ -489,6 +489,10 @@ static QemuOptsList qemu_fw_cfg_opts = {
             .name = "string",
             .type = QEMU_OPT_STRING,
             .help = "Sets content of the blob to be inserted from a string",
+        }, {
+            .name = "blob_id",
+            .type = QEMU_OPT_STRING,
+            .help = "Sets id of the object generating fw_cfg blob to be used",
         },
         { /* end of list */ }
     },
@@ -2020,7 +2024,7 @@ static int parse_fw_cfg(void *opaque, QemuOpts *opts, Error **errp)
 {
     gchar *buf;
     size_t size;
-    const char *name, *file, *str;
+    const char *name, *file, *str, *blob_id;
     FWCfgState *fw_cfg = (FWCfgState *) opaque;
 
     if (fw_cfg == NULL) {
@@ -2030,14 +2034,17 @@ static int parse_fw_cfg(void *opaque, QemuOpts *opts, Error **errp)
     name = qemu_opt_get(opts, "name");
     file = qemu_opt_get(opts, "file");
     str = qemu_opt_get(opts, "string");
+    blob_id = qemu_opt_get(opts, "blob_id");
 
     /* we need name and either a file or the content string */
-    if (!(nonempty_str(name) && (nonempty_str(file) || nonempty_str(str)))) {
+    if (!(nonempty_str(name)
+          && (nonempty_str(file) || nonempty_str(str) || nonempty_str(blob_id)))
+         ) {
         error_setg(errp, "invalid argument(s)");
         return -1;
     }
-    if (nonempty_str(file) && nonempty_str(str)) {
-        error_setg(errp, "file and string are mutually exclusive");
+    if (nonempty_str(file) && nonempty_str(str) && nonempty_str(blob_id)) {
+        error_setg(errp, "file, string and blob_id are mutually exclusive");
         return -1;
     }
     if (strlen(name) > FW_CFG_MAX_FILE_PATH - 1) {
@@ -2052,6 +2059,8 @@ static int parse_fw_cfg(void *opaque, QemuOpts *opts, Error **errp)
     if (nonempty_str(str)) {
         size = strlen(str); /* NUL terminator NOT included in fw_cfg blob */
         buf = g_memdup(str, size);
+    } else if (nonempty_str(blob_id)) {
+        return fw_cfg_add_from_generator(fw_cfg, name, blob_id, errp);
     } else {
         GError *err = NULL;
         if (!g_file_get_contents(file, &buf, &size, &err)) {
-- 
2.21.3

On 05/19/20 20:20, Philippe Mathieu-Daudé wrote:
> The 'blob_id' argument refers to a QOM object able to produce
> data consumable by the fw_cfg device. The producer object must
> implement the FW_CFG_DATA_GENERATOR interface.

OK, this answers my OBJECT_CHECK() question under patch #1 (in the
negative -- an assert would be wrong).

>
> Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com>
> ---
>  softmmu/vl.c | 17 +++++++++++++----
>  1 file changed, 13 insertions(+), 4 deletions(-)
>
> diff --git a/softmmu/vl.c b/softmmu/vl.c
> index ae5451bc23..f76c53ad2e 100644
> --- a/softmmu/vl.c
> +++ b/softmmu/vl.c
> @@ -489,6 +489,10 @@ static QemuOptsList qemu_fw_cfg_opts = {
>              .name = "string",
>              .type = QEMU_OPT_STRING,
>              .help = "Sets content of the blob to be inserted from a string",
> +        }, {
> +            .name = "blob_id",
> +            .type = QEMU_OPT_STRING,
> +            .help = "Sets id of the object generating fw_cfg blob to be used",
>          },
>          { /* end of list */ }
>      },
> @@ -2020,7 +2024,7 @@ static int parse_fw_cfg(void *opaque, QemuOpts *opts, Error **errp)
>  {
>      gchar *buf;
>      size_t size;
> -    const char *name, *file, *str;
> +    const char *name, *file, *str, *blob_id;
>      FWCfgState *fw_cfg = (FWCfgState *) opaque;
>
>      if (fw_cfg == NULL) {
> @@ -2030,14 +2034,17 @@ static int parse_fw_cfg(void *opaque, QemuOpts *opts, Error **errp)
>      name = qemu_opt_get(opts, "name");
>      file = qemu_opt_get(opts, "file");
>      str = qemu_opt_get(opts, "string");
> +    blob_id = qemu_opt_get(opts, "blob_id");
>
>      /* we need name and either a file or the content string */

(1) Please update this comment. If the option is given, we need the
name, and exactly one of: file, content string, blob_id.

> -    if (!(nonempty_str(name) && (nonempty_str(file) || nonempty_str(str)))) {
> +    if (!(nonempty_str(name)
> +          && (nonempty_str(file) || nonempty_str(str) || nonempty_str(blob_id)))
> +         ) {
>          error_setg(errp, "invalid argument(s)");
>          return -1;
>      }

(2) Coding style: does QEMU keep operators on the left or on the right
when breaking subconditions to new lines? (I vaguely recall "to the
right", but I could be wrong... Well, "hw/nvram/fw_cfg.c" has at least 7
examples of the operator being on the right.)

> -    if (nonempty_str(file) && nonempty_str(str)) {
> -        error_setg(errp, "file and string are mutually exclusive");
> +    if (nonempty_str(file) && nonempty_str(str) && nonempty_str(blob_id)) {
> +        error_setg(errp, "file, string and blob_id are mutually exclusive");
>          return -1;
>      }

(3) I believe this catches only when all three of name/string/blob_id
are given. But we should continue catching "two given".

How about reworking both "if"s, *and* the comment at (1) at the same
time, into:

    if (!nonempty_str(name) ||
        nonempty_str(file) + nonempty_str(str) + nonempty_str(blob_id) != 1) {
        error_setg(errp, "name, plus exactly one of file, string and blob_id, "
                   "are needed");
        return -1;
    }

(Regarding the addition, nonempty_str() returns a "bool", which is a
macro to _Bool, which is promoted to "int" or "unsigned int".)

>      if (strlen(name) > FW_CFG_MAX_FILE_PATH - 1) {
> @@ -2052,6 +2059,8 @@ static int parse_fw_cfg(void *opaque, QemuOpts *opts, Error **errp)
>      if (nonempty_str(str)) {
>          size = strlen(str); /* NUL terminator NOT included in fw_cfg blob */
>          buf = g_memdup(str, size);
> +    } else if (nonempty_str(blob_id)) {
> +        return fw_cfg_add_from_generator(fw_cfg, name, blob_id, errp);
>      } else {
>          GError *err = NULL;
>          if (!g_file_get_contents(file, &buf, &size, &err)) {
>

(4) The "-fw_cfg" command line option is documented in both the qemu(1)
manual, and the "docs/specs/fw_cfg.txt" file.

I think we may have to update those. In particular I mean *where* the
option is documented (in both texts).

In the manual, "-fw_cfg" is currently under "Debug/Expert options", but
that will no longer apply (I think?) after this series.

Similarly, in "docs/specs/fw_cfg.txt", the section is called "Externally
Provided Items" -- but that might not be strictly true any more either.

Maybe leave the current "-fw_cfg" mentions in peace, and document
"-fw_cfg blob_id=..." separately (in different docs sections)? The
"fw_cfg generators" concept could deserve dedicated sections.

Sorry that I can't make a good concrete suggestion. :(

Thanks,
Laszlo

On 5/20/20 12:34 AM, Laszlo Ersek wrote:
> On 05/19/20 20:20, Philippe Mathieu-Daudé wrote:
>> The 'blob_id' argument refers to a QOM object able to produce
>> data consumable by the fw_cfg device. The producer object must
>> implement the FW_CFG_DATA_GENERATOR interface.
> 
> OK, this answers my OBJECT_CHECK() question under patch #1 (in the
> negative -- an assert would be wrong).
> 
>>
>> Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com>
>> ---
>>  softmmu/vl.c | 17 +++++++++++++----
>>  1 file changed, 13 insertions(+), 4 deletions(-)
>>
>> diff --git a/softmmu/vl.c b/softmmu/vl.c
>> index ae5451bc23..f76c53ad2e 100644
>> --- a/softmmu/vl.c
>> +++ b/softmmu/vl.c
>> @@ -489,6 +489,10 @@ static QemuOptsList qemu_fw_cfg_opts = {
>>              .name = "string",
>>              .type = QEMU_OPT_STRING,
>>              .help = "Sets content of the blob to be inserted from a string",
>> +        }, {
>> +            .name = "blob_id",
>> +            .type = QEMU_OPT_STRING,
>> +            .help = "Sets id of the object generating fw_cfg blob to be used",
>>          },
>>          { /* end of list */ }
>>      },
>> @@ -2020,7 +2024,7 @@ static int parse_fw_cfg(void *opaque, QemuOpts *opts, Error **errp)
>>  {
>>      gchar *buf;
>>      size_t size;
>> -    const char *name, *file, *str;
>> +    const char *name, *file, *str, *blob_id;
>>      FWCfgState *fw_cfg = (FWCfgState *) opaque;
>>
>>      if (fw_cfg == NULL) {
>> @@ -2030,14 +2034,17 @@ static int parse_fw_cfg(void *opaque, QemuOpts *opts, Error **errp)
>>      name = qemu_opt_get(opts, "name");
>>      file = qemu_opt_get(opts, "file");
>>      str = qemu_opt_get(opts, "string");
>> +    blob_id = qemu_opt_get(opts, "blob_id");
>>
>>      /* we need name and either a file or the content string */
> 
> (1) Please update this comment. If the option is given, we need the
> name, and exactly one of: file, content string, blob_id.
> 
>> -    if (!(nonempty_str(name) && (nonempty_str(file) || nonempty_str(str)))) {
>> +    if (!(nonempty_str(name)
>> +          && (nonempty_str(file) || nonempty_str(str) || nonempty_str(blob_id)))
>> +         ) {
>>          error_setg(errp, "invalid argument(s)");
>>          return -1;
>>      }
> 
> (2) Coding style: does QEMU keep operators on the left or on the right
> when breaking subconditions to new lines? (I vaguely recall "to the
> right", but I could be wrong... Well, "hw/nvram/fw_cfg.c" has at least 7
> examples of the operator being on the right.)

You are right, I have been confused with a recommendation from Eric
Blake, but it was about shell script, not C.

> 
>> -    if (nonempty_str(file) && nonempty_str(str)) {
>> -        error_setg(errp, "file and string are mutually exclusive");
>> +    if (nonempty_str(file) && nonempty_str(str) && nonempty_str(blob_id)) {
>> +        error_setg(errp, "file, string and blob_id are mutually exclusive");
>>          return -1;
>>      }
> 
> (3) I believe this catches only when all three of name/string/blob_id
> are given. But we should continue catching "two given".
> 
> How about reworking both "if"s, *and* the comment at (1) at the same
> time, into:
> 
>     if (!nonempty_str(name) ||
>         nonempty_str(file) + nonempty_str(str) + nonempty_str(blob_id) != 1) {
>         error_setg(errp, "name, plus exactly one of file, string and blob_id, "
>                    "are needed");
>         return -1;
>     }
> 
> (Regarding the addition, nonempty_str() returns a "bool", which is a
> macro to _Bool, which is promoted to "int" or "unsigned int".)
> 
>>      if (strlen(name) > FW_CFG_MAX_FILE_PATH - 1) {
>> @@ -2052,6 +2059,8 @@ static int parse_fw_cfg(void *opaque, QemuOpts *opts, Error **errp)
>>      if (nonempty_str(str)) {
>>          size = strlen(str); /* NUL terminator NOT included in fw_cfg blob */
>>          buf = g_memdup(str, size);
>> +    } else if (nonempty_str(blob_id)) {
>> +        return fw_cfg_add_from_generator(fw_cfg, name, blob_id, errp);
>>      } else {
>>          GError *err = NULL;
>>          if (!g_file_get_contents(file, &buf, &size, &err)) {
>>
> 
> (4) The "-fw_cfg" command line option is documented in both the qemu(1)
> manual, and the "docs/specs/fw_cfg.txt" file.
> 
> I think we may have to update those. In particular I mean *where* the
> option is documented (in both texts).

Oh I forgot this part, thanks.

> 
> In the manual, "-fw_cfg" is currently under "Debug/Expert options", but
> that will no longer apply (I think?) after this series.

Well I'm not sure, the intent is the same, targeting mostly libvirt as
management interface; other uses are for "experts".

> 
> Similarly, in "docs/specs/fw_cfg.txt", the section is called "Externally
> Provided Items" -- but that might not be strictly true any more either.
> 
> Maybe leave the current "-fw_cfg" mentions in peace, and document
> "-fw_cfg blob_id=..." separately (in different docs sections)? The
> "fw_cfg generators" concept could deserve dedicated sections.
> 
> Sorry that I can't make a good concrete suggestion. :(

Thanks for the detailed review!

> 
> Thanks,
> Laszlo
> 

On Tue, May 19, 2020 at 08:20:21PM +0200, Philippe Mathieu-Daudé wrote:
> The 'blob_id' argument refers to a QOM object able to produce
> data consumable by the fw_cfg device. The producer object must
> implement the FW_CFG_DATA_GENERATOR interface.
> 
> Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com>
> ---
>  softmmu/vl.c | 17 +++++++++++++----
>  1 file changed, 13 insertions(+), 4 deletions(-)
> 
> diff --git a/softmmu/vl.c b/softmmu/vl.c
> index ae5451bc23..f76c53ad2e 100644
> --- a/softmmu/vl.c
> +++ b/softmmu/vl.c
> @@ -489,6 +489,10 @@ static QemuOptsList qemu_fw_cfg_opts = {
>              .name = "string",
>              .type = QEMU_OPT_STRING,
>              .help = "Sets content of the blob to be inserted from a string",
> +        }, {
> +            .name = "blob_id",
> +            .type = QEMU_OPT_STRING,
> +            .help = "Sets id of the object generating fw_cfg blob to be used",
>          },

<bikeshed>

I wonder if "generator_id" or "gen_id" is more appropriate as the property
name

</bikeshed>


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