On Fri, Mar 24, 2017 at 02:42:47PM -0500, Brijesh Singh wrote: > > On 03/24/2017 10:40 AM, Stefan Hajnoczi wrote: > > > > > Having one security policy doesn't make sense to me. As mentioned, > > there are many different areas of QEMU that have security relevant > > configuration. They are all unrelated so combining them into one object > > with vague parameter names like "debug" makes for a confusing > > command-line interface. > > > > If the object is called sev-security-policy then I'm happy. > > > > Works for with me but one of the feedback was to use security-policy [1]. > IIRC, the main reason for using 'security-policy' instead of > 'sev-security-policy' > was to add a layer of abstraction so that in future if other platforms > supports > memory encryption in slightly different way then all we need to do is to > create > new object without needing to add a new parameter in -machine. > > [1] http://marc.info/?l=qemu-devel&m=147388592213137&w=2 > > How about using 'memory-encryption-id' instead of security-policy ? If user > wants > to launch SEV guest then memory-encryption-id should be set SEV specific > object. > Something like this: > > -machine ..,memory-encryption-id=sev0 \ > -object sev-guest,id=sev,debug=off,launch=launch0 \ > -object sev-launch-info,id=launch0 \
Something like that sounds good. I think "-id" typically isn't included in the option name. So just the following is fine: -machine memory-encryption=sev0 \ ... Other examples: -device virtio-blk-pci,drive=drive0 and -device e1000,netdev=netdev0. Stefan
signature.asc
Description: PGP signature
