2017-03-22 18:06+0200, Michael S. Tsirkin: > On Wed, Mar 22, 2017 at 04:59:06PM +0100, Radim Krčmář wrote: >> QEMU does not allocate based on machine's max_cpus, but only uses it to >> limit the maximum selected by user and the actual limit of VCPUs is >> enfoced by other components: >> - machine without vIOMMU ends at 255 VCPUs >> - TCG currently doesn't support x2APIC, so it also ends below 256 >> - KVM with vIOMMU cannot exceed the KVM limit (currently 288) >> >> Using a big value should bring no drawbacks and the benefit is that >> components (especially out-of-tree KVM) can bump their limits without >> touching machine's max_cpus. >> >> max_cpus is unsigned, but it is treated as signed at least in printf and >> the other two billion VCPU won't be needed for a while, so we can ignore >> possible bugs by using signed max. >> >> Signed-off-by: Radim Krčmář <rkrc...@redhat.com> >> --- >> Should the 2.9 machine type still have 288? > > It doesn't look like a bugfix to me. > So if we can defer past 2.9 that would be best IMO.
Sure, I'll wait until the 2.10 machine type pops up. Thanks.
