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

[Wei Liu <wei.liu2@xxxxxxxxxx>]

On Fri, Feb 23, 2018 at 01:50:05AM -0700, Jan Beulich wrote:
> >>> 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.

AIUI this change has made the structure larger by extending the trailing
array. The resulting structure still fits into one page. At least to me
the new ABI is still compatible with the old.

The commit you mentioned is different because it completely breaks ABI
compatibility.

Wei.

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