Windows desktop releases are generally restricted to 1 or 2 CPU sockets. bhyve by default will assign configured vCPUs to a socket. This has the effect of Windows desktops only seeing 1/2 vCPUs instead of the configured numbers. While there is a workaround available to configure the number of cores/socket, or threads/core, this is a global setting and applies to all guests, whereas it need only be a on a per-guest basis. (see http://docs.FreeBSD.org/cgi/mid.cgi?b26b6124-7ac6-0408-3016-f5678ad144d0 for more details) This bug will track the modification of bhyve to allow the setting of these values on a per-guest basis.
Watching this. I find it silly that we can't specify more than 16 cores without a kernel and world rebuild.
Referencing https://reviews.freebsd.org/D9930
D9930 is committed to head, waiting on merge to stable/11 to close this PR
(In reply to Tsaukpaetra from comment #1) I have WIP to fix that very issue, but first I had to fix several issues that do not even allow us to go above 21 or 24 CPU's, corrections for that which allow us to go up to 254 vCPU are now in review: https://reviews.freebsd.org/D18815 https://reviews.freebsd.org/D18816 https://reviews.freebsd.org/D18998 and first steps in removing VM_MAXCPU are also in review: https://reviews.freebsd.org/D18846 https://reviews.freebsd.org/D18755 Also you do not need to rebuild the kernel, there is a shorter list of what needs to be rebuilt. The most overlooked one is to run (cd /usr/src; make includes) so that the change of vmm.h gets installed into /usr/include, after that you just need to rebuild vmm.ko, libvmmapi, and bhyve/bhyveload. This work is still not merged to stable/11, iirc I ran into other intervening commits that have blocked that merge.
The topology code was commited pre stable/12 creation, so no mfc needed there. I'll see about getting D9930 merged to stable/11.
^Triage: committed back in 2019.