Brijesh Singh <brijesh.si...@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.si...@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.
