Re: [Xen-devel] [RFC Patch v4 8/8] x86/hvm: bump the maximum number of vcpus to 512

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 23.02.18 at 19:11, <roger.pau@xxxxxxxxxx> wrote:
> On Wed, Dec 06, 2017 at 03:50:14PM +0800, Chao Gao wrote:
>> Signed-off-by: Chao Gao <chao.gao@xxxxxxxxx>
>> ---
>>  xen/include/public/hvm/hvm_info_table.h | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>> 
>> diff --git a/xen/include/public/hvm/hvm_info_table.h 
> b/xen/include/public/hvm/hvm_info_table.h
>> index 08c252e..6833a4c 100644
>> --- a/xen/include/public/hvm/hvm_info_table.h
>> +++ b/xen/include/public/hvm/hvm_info_table.h
>> @@ -32,7 +32,7 @@
>>  #define HVM_INFO_PADDR       ((HVM_INFO_PFN << 12) + HVM_INFO_OFFSET)
>>  
>>  /* Maximum we can support with current vLAPIC ID mapping. */
>> -#define HVM_MAX_VCPUS        128
>> +#define HVM_MAX_VCPUS        512
> 
> Wow, that looks like a pretty big jump. I certainly don't have access
> to any box with this number of vCPUs, so that's going to be quite hard
> to test. What the reasoning behind this bump? Is hardware with 512
> ways expected soon-ish?
> 
> Also osstest is not even able to test the current limit, so I would
> maybe bump this to 256, but as I expressed in other occasions I don't
> feel comfortable with have a number of vCPUs that the current test
> system doesn't have hardware to test with.

I think implementation limit and supported limit need to be clearly
distinguished here. Therefore I'd put the question the other way
around: What's causing the limit to be 512, rather than 1024,
4096, or even 4G-1 (x2APIC IDs are 32 bits wide, after all)?

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel