From: "Philippe Mathieu-Daudé" <philmd@redhat.com>
To: Laszlo Ersek <lersek@redhat.com>, qemu-devel@nongnu.org
Cc: "Paolo Bonzini" <pbonzini@redhat.com>,
"Daniel P. Berrangé" <berrange@redhat.com>,
"Eduardo Habkost" <ehabkost@redhat.com>,
"Gerd Hoffmann" <kraxel@redhat.com>
Subject: Re: [PATCH v6 2/5] softmmu/vl: Let -fw_cfg option take a 'blob_id' argument
Date: Thu, 28 May 2020 14:07:06 +0200 [thread overview]
Message-ID: <41f963dc-ac0f-7a7d-9d19-fcbd2e846926@redhat.com> (raw)
In-Reply-To: <ce1f0c80-f26b-40de-6d5b-2dc8f92fcfa2@redhat.com>
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
>
next prev parent reply other threads:[~2020-05-28 12:08 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-05-19 18:20 [PATCH v6 0/5] fw_cfg: Add FW_CFG_DATA_GENERATOR; crypto: Add tls-cipher-suites Philippe Mathieu-Daudé
2020-05-19 18:20 ` [PATCH v6 1/5] hw/nvram/fw_cfg: Add the FW_CFG_DATA_GENERATOR interface Philippe Mathieu-Daudé
2020-05-19 22:01 ` Laszlo Ersek
2020-05-28 14:54 ` Philippe Mathieu-Daudé
2020-05-19 18:20 ` [PATCH v6 2/5] softmmu/vl: Let -fw_cfg option take a 'blob_id' argument Philippe Mathieu-Daudé
2020-05-19 22:34 ` Laszlo Ersek
2020-05-28 12:07 ` Philippe Mathieu-Daudé [this message]
2020-05-27 11:38 ` Daniel P. Berrangé
2020-05-19 18:20 ` [RFC PATCH v6 3/5] softmmu/vl: Allow -fw_cfg 'blob_id' option to set any file pathname Philippe Mathieu-Daudé
2020-05-19 18:22 ` Philippe Mathieu-Daudé
2020-05-19 22:45 ` Laszlo Ersek
2020-05-28 17:03 ` Philippe Mathieu-Daudé
2020-05-19 18:20 ` [PATCH v6 4/5] crypto: Add tls-cipher-suites object Philippe Mathieu-Daudé
2020-05-19 23:24 ` Laszlo Ersek
2020-05-27 11:36 ` Daniel P. Berrangé
2020-05-28 10:17 ` Philippe Mathieu-Daudé
2020-05-19 18:20 ` [PATCH v6 5/5] crypto/tls-cipher-suites: Product fw_cfg consumable blob Philippe Mathieu-Daudé
2020-05-19 22:49 ` Laszlo Ersek
2020-05-27 11:29 ` [PATCH v6 0/5] fw_cfg: Add FW_CFG_DATA_GENERATOR; crypto: Add tls-cipher-suites Philippe Mathieu-Daudé
2020-05-27 11:33 ` Daniel P. Berrangé
2020-05-27 11:34 ` 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=41f963dc-ac0f-7a7d-9d19-fcbd2e846926@redhat.com \
--to=philmd@redhat.com \
--cc=berrange@redhat.com \
--cc=ehabkost@redhat.com \
--cc=kraxel@redhat.com \
--cc=lersek@redhat.com \
--cc=pbonzini@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).