On 04/11/19 20:10, 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".
>
> 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.
On second thought, if we're sure the hardware / encryption engine will
always have this kind of limitation, then mandatory looks fine.
Thanks
Laszlo
