Bug 215077 - bhyve should allow per-guest configuration of CPU socket/cores/threads
Summary: bhyve should allow per-guest configuration of CPU socket/cores/threads
Status: In Progress
Alias: None
Product: Base System
Classification: Unclassified
Component: bin (show other bugs)
Version: CURRENT
Hardware: amd64 Any
: --- Affects Many People
Assignee: Rodney W. Grimes
Keywords: bhyve
Depends on:
Reported: 2016-12-05 19:12 UTC by Peter Grehan
Modified: 2019-02-20 05:09 UTC (History)
3 users (show)

See Also:
rgrimes: mfc-stable12-
rgrimes: mfc-stable11+


Note You need to log in before you can comment on or make changes to this bug.
Description Peter Grehan freebsd_committer 2016-12-05 19:12:31 UTC
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.
Comment 1 Tsaukpaetra 2017-03-17 22:49:24 UTC
Watching this.

I find it silly that we can't specify more than 16 cores without a kernel and world rebuild.
Comment 2 Tsaukpaetra 2017-03-20 21:44:20 UTC
Referencing https://reviews.freebsd.org/D9930
Comment 3 Rodney W. Grimes freebsd_committer 2018-06-11 14:12:29 UTC
D9930 is committed to head, waiting on merge to stable/11 to close this PR
Comment 4 Rodney W. Grimes freebsd_committer 2019-02-17 16:20:26 UTC
(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:

and first steps in removing VM_MAXCPU are also in review:

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.
Comment 5 Rodney W. Grimes freebsd_committer 2019-02-20 05:09:38 UTC
The topology code was commited pre stable/12 creation, so no mfc needed there.  I'll see about getting D9930 merged to stable/11.