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

From: Brijesh Singh <brijesh.singh@amd.com>
To: Markus Armbruster <armbru@redhat.com>
Cc: 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>,
	"Daniel P. Berrangé" <berrange@redhat.com>,
	kvm@vger.kernel.org, "Michael Roth" <michael.roth@amd.com>,
	"Eduardo Habkost" <ehabkost@redhat.com>
Subject: Re: [RFC PATCH 2/6] i386/sev: extend sev-guest property to include SEV-SNP
Date: Wed, 14 Jul 2021 09:18:09 -0500	[thread overview]
Message-ID: <5017886b-c075-8997-2c21-c04ddbd5e95e@amd.com> (raw)
In-Reply-To: <87h7gy4990.fsf@dusky.pond.sub.org>

On 7/13/21 8:46 AM, 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?

I will take a look at the blockdev and try modeling after that. if I run
into any questions then I will ask. thanks for the pointer Markus.

-Brijesh