qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Singh, Brijesh
Subject: Re: [Qemu-devel] [PATCH] target/i386: sev: add 'sev-max-guests' field to 'query-sev-capabilities'
Date: Thu, 11 Apr 2019 19:02:21 +0000


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.

> 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.
> 


reply via email to

[Prev in Thread] Current Thread [Next in Thread]