>>> On 22.02.18 at 19:46, <wei.l...@citrix.com> 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 Xenemail@example.com https://lists.xenproject.org/mailman/listinfo/xen-devel