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.