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

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 22.02.18 at 19:46, <wei.liu2@xxxxxxxxxx> wrote:
> On Wed, Dec 06, 2017 at 03:50:14PM +0800, Chao Gao wrote:
>> --- 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
> 
> I checked a few places where this is used, bumping the number doesn't
> seem to be harmful on the surface.
> 
> Of course there is the question how many CPUs can upstream support,
> I think it is still under argument at the moment.

Leaving the latter aside, it is never okay to simply change a #define
in the public interface. See e.g. fb442e2171 ("x86_64: allow more
vCPU-s per guest"), where we've already gone a somewhat harsh
route by dropping the original #define altogether (thus at least
causing build failures for consumers), taking the position that it
wasn't correct to expose the value in the first place.

Hence at the very least I can't see how struct hvm_info_table
(in the same public header) can be left alone with this change.

Jan


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