2017-08-11 10:11+0200, David Hildenbrand: > On 11.08.2017 09:49, Lan Tianyu wrote: >> Hi Konrad: >> Thanks for your review. >> >> On 2017年08月11日 01:50, Konrad Rzeszutek Wilk wrote: >>> On Thu, Aug 10, 2017 at 06:00:59PM +0800, Lan Tianyu wrote: >>>> Intel Xeon phi chip will support 352 logical threads. For HPC usage >>>> case, it will create a huge VM with vcpu number as same as host cpus. This >>>> patch is to increase max vcpu number to 352. >>> >>> Why not 1024 or 4096? >> >> This is on demand. We can set a higher number since KVM already has >> x2apic and vIOMMU interrupt remapping support. >> >>> >>> Are there any issues with increasing the value from 288 to 352 right now? >> >> No found. Yeah, the only issue until around 2^20 (when we reach the maximum of logical x2APIC addressing) should be the size of per-VM arrays when only few VCPUs are going to be used. >>> Also perhaps this should be made in an Kconfig entry? >> >> That will be anther option but I find different platforms will define >> different MAX_VCPU. If we introduce a generic Kconfig entry, different >> platforms should have different range. >> >> Radim & Paolo, Could you give some input? In qemu thread, we will set >> max vcpu to 8192 for x86 VM. In KVM, The length of vcpu pointer array in >> struct kvm and dest_vcpu_bitmap in kvm_irq_delivery_to_apic() are >> specified by KVM_MAX_VCPUS. Should we keep align with Qemu? That would be great. > commit 682f732ecf7396e9d6fe24d44738966699fae6c0 > Author: Radim Krčmář <rkrcmar@xxxxxxxxxx> > Date: Tue Jul 12 22:09:29 2016 +0200 > > KVM: x86: bump MAX_VCPUS to 288 > > 288 is in high demand because of Knights Landing CPU. > We cannot set the limit to 640k, because that would be wasting space. > > I think we want to keep it small as long as possible. I remember a patch > series from Radim which would dynamically allocate memory for these > arrays (using a new VM creation ioctl, specifying the max # of vcpus). > Wonder what happened to that (I remember requesting a simply remalloc > instead of a new VM creation ioctl :] ). Eh, I forgot about them ... I didn't like the dynamic allocation as we would need to protect the memory, which would result in a much bigger changeset, or fragile macros. I can't recall the disgust now, so I'll send a RFC with the dynamic version to see how it turned out. Thanks.
