Re: [Qemu-devel] [RFC PATCH v4 06/20] core: add new security-policy object

[Brijesh Singh <brijesh.singh@amd.com>]

On 03/27/2017 07:04 AM, Stefan Hajnoczi wrote:
> 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.


Sounds good. I will take care of this in next rev. thanks for review

-Brijesh