vmm: Convert VM_MAXCPU into a loader tunable hw.vmm.maxcpu.

[jhb]

Summary

The default is now the number of physical CPUs in the system rather
than 16.

[corvink]

sys/amd64/vmm/vmm.c

311

Just a suggestion!

603

Shouldn't we check if this malloc was successfully?

[markj]

sys/amd64/vmm/vmm.c

320

Maybe print a message if the value is clamped?

324

vmm doesn't use SYSINITs anywhere else except for stats; all initialization is done from vmm_init(). Why deviate from that?

SI_SUB_TUNABLE is also kind of strange to me: mp_ncpus isn't initialized at that stage of the kernel's boot. I understand that it works because vmm is always a kernel module and their sysinits are processed later even if preloaded, but if some soul tries to compile vmm into the kernel, this will bite them.

603

malloc(M_WAITOK) is guaranteed to not return a NULL pointer.

[jhb]

sys/amd64/vmm/vmm.c

324

Hmm, just used to using SI_SUB_TUNABLES out of habit for tunable, but yes, mp_ncpus isn't valid then. I can move it.

[jhb]

Move into vmm_init

[jhb]

sys/amd64/vmm/vmm.c

311

I think I should probably explain better the reason for - 1. I think it's to ensure we have at least one free pid value, or maybe it's to permit the use of '-1' for vcpu values (though I've mostly removed those uses I think).

[jhb]

Add comment for -1 in VM_MAXCPU

[corvink]

sys/amd64/vmm/vmm.c

311

Your comment explains that the number of maxcpus is limited by the uint16_t type. So, the intention of my suggestion was to use the UINT16_MAX macro. You don't have to use it. It's just a suggestion.