qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
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.
> 


  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).