Re: [Qemu-devel] [PATCH] target/i386: sev: add 'sev-max-guests' field to 'query-sev-capabilities'

[Laszlo Ersek]

On 04/11/19 21:02, Singh, Brijesh wrote:
> 
> 
> On 4/11/19 1:10 PM, Laszlo Ersek wrote:
>> On 04/11/19 19:59, Singh, Brijesh wrote:
>>> There are limited numbers of the SEV guests that can be run concurrently.
>>> A management applications may need to know this limit so that it can place
>>> SEV VMs on hosts which have suitable resources available.
>>>
>>> Currently, this limit is not exposed to the application. Add a new
>>> 'sev-max-guest' field in the query-sev-capabilities to provide this
>>> information.
>>>
>>> Cc: Paolo Bonzini <address@hidden>
>>> Cc: Markus Armbruster <address@hidden>
>>> Cc: Eric Blake <address@hidden>
>>> Cc: Daniel P. Berrangé <address@hidden>
>>> Cc: Laszlo Ersek <address@hidden>
>>> Cc: Erik Skultety <address@hidden>
>>> Signed-off-by: Brijesh Singh <address@hidden>
>>> ---
>>>   qapi/target.json  | 6 ++++--
>>>   target/i386/sev.c | 6 ++++--
>>>   2 files changed, 8 insertions(+), 4 deletions(-)
>>>
>>> diff --git a/qapi/target.json b/qapi/target.json
>>> index 1d4d54b600..b45121d30b 100644
>>> --- a/qapi/target.json
>>> +++ b/qapi/target.json
>>> @@ -183,7 +183,8 @@
>>>     'data': { 'pdh': 'str',
>>>               'cert-chain': 'str',
>>>               'cbitpos': 'int',
>>> -            'reduced-phys-bits': 'int'},
>>> +            'reduced-phys-bits': 'int',
>>> +            'sev-max-guests': 'int'},
>>
>> Would it be useful to make this new field optional? E.g. if it was
>> missing, libvirtd could assume "no limit".
>>
> 
> I am not sure if we need to make this field optional - mainly because
> in SEV context hardware will always have some limits (at least in
> foreseeable future). The architecture provides us a CPUID to query
> this capabilities so I am assuming that future CPUs will populate
> some values in it.

Yup, sounds reasonable. Please resubmit with Daniel's request addressed
and I'll be happy to R-b.

Erik: can you please ACK too?

Thanks!
Laszlo

>> Again, not sure if that's useful, but it's not hard to introduce the
>> field as optional now. Removing mandatory fields later is impossible.
>>
>