On Tue, Jul 13, 2021 at 03:46:19PM +0200, Markus Armbruster wrote: > Brijesh Singh <brijesh.singh@xxxxxxx> 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@xxxxxxx> > > 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. >
