>>> On 23.02.18 at 19:11, <roger....@citrix.com> wrote: > On Wed, Dec 06, 2017 at 03:50:14PM +0800, Chao Gao wrote: >> Signed-off-by: Chao Gao <chao....@intel.com> >> --- >> 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@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
