Re: [RFC PATCH 2/6] i386/sev: extend sev-guest property to include SEV-SNP

From: Markus Armbruster <armbru@redhat.com>
To: Brijesh Singh <brijesh.singh@amd.com>
Cc: "Tom Lendacky" <thomas.lendacky@amd.com>,
	"Daniel P. Berrangé" <berrange@redhat.com>,
	"Eduardo Habkost" <ehabkost@redhat.com>,
	kvm@vger.kernel.org, "Michael S . Tsirkin" <mst@redhat.com>,
	"Connor Kuehl" <ckuehl@redhat.com>,
	"Michael Roth" <michael.roth@amd.com>,
	"James Bottomley" <jejb@linux.ibm.com>,
	qemu-devel@nongnu.org,
	"Dr . David Alan Gilbert" <dgilbert@redhat.com>,
	"Dov Murik" <dovmurik@linux.ibm.com>,
	"Paolo Bonzini" <pbonzini@redhat.com>,
	"Philippe Mathieu-Daudé" <philmd@redhat.com>,
	"David Gibson" <david@gibson.dropbear.id.au>
Subject: Re: [RFC PATCH 2/6] i386/sev: extend sev-guest property to include SEV-SNP
Date: Tue, 13 Jul 2021 15:46:19 +0200	[thread overview]
Message-ID: <87h7gy4990.fsf@dusky.pond.sub.org> (raw)
In-Reply-To: <20210709215550.32496-3-brijesh.singh@amd.com> (Brijesh Singh's message of "Fri, 9 Jul 2021 16:55:46 -0500")

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?

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