On 11/04/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 <pbonz...@redhat.com>
>>> Cc: Markus Armbruster <arm...@redhat.com>
>>> Cc: Eric Blake <ebl...@redhat.com>
>>> Cc: Daniel P. Berrangé <berra...@redhat.com>
>>> Cc: Laszlo Ersek <ler...@redhat.com>
>>> Cc: Erik Skultety <eskul...@redhat.com>
>>> Signed-off-by: Brijesh Singh <brijesh.si...@amd.com>
>>> ---
>>> 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.
Since this field is not specific to guest configuration, I don't think
it belongs in query-sev-capabilities; QEMU does not care about >1 guest.
Paolo
