On 01/07/2016 16:38, Radim Krčmář wrote: >> > Should it? > Yes, x2APIC ID cannot be changed in hardware and is initialized to the > intitial APIC ID. > Letting LAPIC_SET change x2APIC ID would allow scenarios where userspace > reuses old VMs instead of building new ones after reconfiguration. > I don't think it's a sensible use case and it it is currently broken, > because we don't exit to userspace when changing APIC mode, so KVM would > just set APIC ID to VCPU ID on any transition and userspace couldn't > amend it. > >> > According to QEMU if you have e.g. 3 cores per socket one >> > socket take 4 APIC IDs. For Knights Landing the "worst" prime factor in >> > 288 is 3^2 so you need APIC IDs up to 288 * (4/3)^2 = 512. > The topology can result in sparse APIC ID and APIC ID is initialized > from VCPU ID, so userspace has to pick VCPU ID accordingly. Right, I was confusing KVM_MAX_VCPUS and KVM_MAX_VCPU_ID. So the overflow case cannot happen and neither can the 32GB allocation. On the other hand, I suspect you need to bump KVM_MAX_VCPU_ID beyond its current default setting (which is equal to KVM_MAX_VCPUS), up to 511 or 1023. Thanks, Paolo -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
