From: Michael Roth <michael.roth@amd.com>
To: "Markus Armbruster" <armbru@redhat.com>,
"Daniel P. Berrangé" <berrange@redhat.com>
Cc: "Brijesh Singh" <brijesh.singh@amd.com>,
qemu-devel@nongnu.org, "Connor Kuehl" <ckuehl@redhat.com>,
"Philippe Mathieu-Daudé" <philmd@redhat.com>,
"Michael S . Tsirkin" <mst@redhat.com>,
"James Bottomley" <jejb@linux.ibm.com>,
"Dr . David Alan Gilbert" <dgilbert@redhat.com>,
"Tom Lendacky" <thomas.lendacky@amd.com>,
"Paolo Bonzini" <pbonzini@redhat.com>,
"Dov Murik" <dovmurik@linux.ibm.com>,
"David Gibson" <david@gibson.dropbear.id.au>,
kvm@vger.kernel.org, "Eduardo Habkost" <ehabkost@redhat.com>
Subject: Re: [RFC PATCH 2/6] i386/sev: extend sev-guest property to include SEV-SNP
Date: Tue, 20 Jul 2021 14:42:12 -0500 [thread overview]
Message-ID: <20210720194212.vjmsktx2ti3apv2d@amd.com> (raw)
In-Reply-To: <87h7gy4990.fsf@dusky.pond.sub.org>
On Tue, Jul 13, 2021 at 03:46:19PM +0200, Markus Armbruster wrote:
> Brijesh Singh <brijesh.singh@amd.com> writes:
>
> > To launch the SEV-SNP guest, a user can specify up to 8 parameters.
> > Passing all parameters through command line can be difficult. To simplify
> > the launch parameter passing, introduce a .ini-like config file that can be
> > used for passing the parameters to the launch flow.
> >
> > The contents of the config file will look like this:
> >
> > $ cat snp-launch.init
> >
> > # SNP launch parameters
> > [SEV-SNP]
> > init_flags = 0
> > policy = 0x1000
> > id_block = "YWFhYWFhYWFhYWFhYWFhCg=="
> >
> >
> > Add 'snp' property that can be used to indicate that SEV guest launch
> > should enable the SNP support.
> >
> > SEV-SNP guest launch examples:
> >
> > 1) launch without additional parameters
> >
> > $(QEMU_CLI) \
> > -object sev-guest,id=sev0,snp=on
> >
> > 2) launch with optional parameters
> > $(QEMU_CLI) \
> > -object sev-guest,id=sev0,snp=on,launch-config=<file>
> >
> > Signed-off-by: Brijesh Singh <brijesh.singh@amd.com>
>
> I acknowledge doing complex configuration on the command line can be
> awkward. But if we added a separate configuration file for every
> configurable thing where that's the case, we'd have too many already,
> and we'd constantly grow more. I don't think this is a viable solution.
>
> In my opinion, much of what we do on the command line should be done in
> configuration files instead. Not in several different configuration
> languages, mind, but using one common language for all our configuration
> needs.
>
> Some of us argue this language already exists: QMP. It can't do
> everything the command line can do, but that's a matter of putting in
> the work. However, JSON isn't a good configuration language[1]. To get
> a decent one, we'd have to to extend JSON[2], or wrap another concrete
> syntax around QMP's abstract syntax.
>
> But this doesn't help you at all *now*.
>
> I recommend to do exactly what we've done before for complex
> configuration: define it in the QAPI schema, so we can use both dotted
> keys and JSON on the command line, and can have QMP, too. Examples:
> -blockdev, -display, -compat.
>
> Questions?
Hi Markus, Daniel,
I'm dealing with similar considerations with some SNP config options
relating to CPUID enforcement, so I've started looking into this as
well, but am still a little confused on the best way to proceed.
I see that -blockdev supports both JSON command-line arguments (via
qobject_input_visitor_new) and dotted keys
(via qobject_input_vistior_new_keyval).
We could introduce a new config group do the same, maybe something specific
to ConfidentialGuestSupport objects, e.g.:
-confidential-guest-support sev-guest,id=sev0,key_a.subkey_b=...
and use the same mechanisms to parse the options, but this seems to
either involve adding a layer of option translations between command-line
and the underlying object properties, or, if we keep the 1:1 mapping
between QAPI-defined keys and object properties, it basically becomes a
way to pass a different Visitor implementation into object_property_set(),
in this case one created by object_input_visitor_new_keyval() instead of
opts_visitor_new().
In either case, genericizing it beyond CGS/SEV would basically be
introducing:
-object2 sev-guest,id=sev0,key_a.subkey_b=...
Which one seems preferable? Or is the answer neither?
I've also been looking at whether this could all be handled via -object,
and it seems -object already supports JSON command-line arguments, and that
switching it from using OptsVisitor to QObjectVisitor for non-JSON case
would be enough to have it handle dotted keys, but I'm not sure what the
fall-out would be compatibility-wise.
All lot of that falls under making sure the QObject/keyval parser is
compatible with existing command-lines parsed via OptsVisitor. One example
where there still seems to be a difference is lack of support for ranges
such as "cpus=1-4" in keyval parser. Daniel had a series that addressed
this:
https://lists.gnu.org/archive/html/qemu-devel/2016-09/msg08248.html
but it doesn't seem to have made it into the tree, which is why I feel like
maybe there are complications with this approach I haven't considered?
Thanks!
-Mike
>
>
> [1] https://www.lucidchart.com/techblog/2018/07/16/why-json-isnt-a-good-configuration-language/
>
> [2] Thanks, but no thanks. Let's make new and interesting mistakes
> instead of repeating old and tired ones.
>
next prev parent reply other threads:[~2021-07-20 19:48 UTC|newest]
Thread overview: 45+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-07-09 21:55 [RFC PATCH 0/6] Add AMD Secure Nested Paging (SEV-SNP) support Brijesh Singh
2021-07-09 21:55 ` [RFC PATCH 1/6] linux-header: add the SNP specific command Brijesh Singh
2021-07-10 20:32 ` Michael S. Tsirkin
2021-07-12 15:48 ` Brijesh Singh
2021-07-19 11:35 ` Dov Murik
2021-07-19 14:40 ` Brijesh Singh
2021-07-09 21:55 ` [RFC PATCH 2/6] i386/sev: extend sev-guest property to include SEV-SNP Brijesh Singh
2021-07-12 6:09 ` Dov Murik
2021-07-12 14:34 ` Dr. David Alan Gilbert
2021-07-12 15:59 ` Brijesh Singh
2021-07-12 16:16 ` Dr. David Alan Gilbert
2021-07-12 14:43 ` Daniel P. Berrangé
2021-07-12 15:56 ` Brijesh Singh
2021-07-12 16:24 ` Daniel P. Berrangé
2021-07-13 13:54 ` Brijesh Singh
2021-07-13 13:46 ` Markus Armbruster
2021-07-14 14:18 ` Brijesh Singh
2021-07-20 19:42 ` Michael Roth [this message]
2021-07-20 21:54 ` Daniel P. Berrangé
2021-07-21 13:08 ` Markus Armbruster
2021-07-22 0:02 ` Michael Roth via
2021-07-13 18:21 ` Eric Blake
2021-07-09 21:55 ` [RFC PATCH 3/6] i386/sev: initialize SNP context Brijesh Singh
2021-07-15 9:32 ` Dov Murik
2021-07-15 13:24 ` Brijesh Singh
2021-07-09 21:55 ` [RFC PATCH 4/6] i386/sev: add the SNP launch start context Brijesh Singh
2021-07-19 12:34 ` Dov Murik
2021-07-19 15:27 ` Brijesh Singh
2021-07-09 21:55 ` [RFC PATCH 5/6] i386/sev: add support to encrypt BIOS when SEV-SNP is enabled Brijesh Singh
2021-07-14 17:08 ` Connor Kuehl
2021-07-14 18:52 ` Brijesh Singh
2021-07-15 5:54 ` Dov Murik
2021-07-19 13:00 ` Dov Murik
2021-07-09 21:55 ` [RFC PATCH 6/6] i386/sev: populate secrets and cpuid page and finalize the SNP launch Brijesh Singh
2021-07-14 17:29 ` Dr. David Alan Gilbert
2021-07-14 18:53 ` Brijesh Singh
2021-07-19 11:24 ` Dov Murik
2021-07-19 14:45 ` Brijesh Singh
2021-07-12 17:00 ` [RFC PATCH 0/6] Add AMD Secure Nested Paging (SEV-SNP) support Tom Lendacky
2021-07-13 8:05 ` Dov Murik
2021-07-13 8:31 ` Dr. David Alan Gilbert
2021-07-13 13:57 ` Brijesh Singh
2021-07-13 14:01 ` Brijesh Singh
2021-07-14 9:52 ` Dr. David Alan Gilbert
2021-07-14 14:23 ` Brijesh Singh
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=20210720194212.vjmsktx2ti3apv2d@amd.com \
--to=michael.roth@amd.com \
--cc=armbru@redhat.com \
--cc=berrange@redhat.com \
--cc=brijesh.singh@amd.com \
--cc=ckuehl@redhat.com \
--cc=david@gibson.dropbear.id.au \
--cc=dgilbert@redhat.com \
--cc=dovmurik@linux.ibm.com \
--cc=ehabkost@redhat.com \
--cc=jejb@linux.ibm.com \
--cc=kvm@vger.kernel.org \
--cc=mst@redhat.com \
--cc=pbonzini@redhat.com \
--cc=philmd@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=thomas.lendacky@amd.com \
/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).