summary refs log tree commit diff stats
path: root/results/classifier/zero-shot/105/graphic/2848
blob: 4a026c83d21702cb7d3d12f4c8d9efdf5d324a3b (plain) (blame)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
graphic: 0.758
instruction: 0.714
device: 0.691
semantic: 0.657
vnc: 0.558
socket: 0.461
other: 0.405
network: 0.305
boot: 0.303
mistranslation: 0.286
KVM: 0.214
assembly: 0.093

i386 max_cpus off by one
Description of problem:
X86 VMs are currently limited to 255 vCPUs (`mc->max_cpus = 255;` in `pc.c`).
The first occurrence i can find of this limit is in d3e9db933f416c9f1c04df4834d36e2315952e42 from 2005 where both `MAX_APICS` and `MAX_CPUS` was set to 255. This is becoming relevant for some people as servers with 256 cores become more available. 

**Can we increase the limit to 256 vCPUs?** 
I think so. 

Today, the APIC id limit (see `apic_id_limit` in `x86-common.c`) is based on the CPU id limit. 
According to the a comment for `typdef uint32_t apic_id_t;` (see `topology.h`), we can have 256 APICs, but more APICs require x2APIC support. 
APIC seems to be no hindrance to increase max_cpus to 256. 

**Can we increase the limit to 512?** Maybe not? We need x2APIC support of which i have no clue. Also there is always a performance risk of exceeding the size at which current data structures work efficiently.