vmm.ko: retire compile time VM_MAXCPU, replace with per VM topology maxcpus

[jhb]

Summary

This patch is work in progress, and not ready to use / test. It will probably cause panics.

First attempts at making VM_MAXCPU tunable, and I'm hoping I'll get some feedback on my approach here:

• Create a tunable maxvcpus
• Replace VM_MAXCPU with maxvcpu in loops and dynamic allocations
• Limit that tunable to 21 for now
• Dynamically allocate arrays of size VM_MAXCPU in
  • vm.vcpu
  • svm_softc.apic_page
  • svm_softc.svm_vcpu
  • vmx.vmcs, vmx.apic_page, vmx.pir_desc, vmx.guest_msrs, vmx.ctx, vmx.cap, vmx.state
• Dynamically define VMM_STAT_ARRAYS
  • IPIS_SENT

[ } Dynamically calculate FADT_OFFSET, HPET_OFFSET, MCFG_OFFSET, FACS_OFFSET, DSDT_OFFSET, and remove the 21 vcpu limitation

Only comment on methodology used at this time, the details in the diff are fluid and not worth spending a lot of time on.
Commit message to contain:

Attribution to fabian.freyer_physik.tu-berlin.de for his work on this

Test Plan

patch is not ready for testing, the presently attached patch is to be replaced with one that compiles and works,
this patch is in need of pulling up to current head. I am just adding Patrick Mooney to the review as I thought he was already on this.

[rgrimes]

I am not sure, but I believe this is pretty much in conflict with what I did in the CPU topology enhancement, D9930

[rgrimes]

Fabian, I have done some other work that moves forward with this concept, mostly correcting stuff that puts limits in place on how high VM_MAXCPU can go, and have WIP that actually changes this to a run time per vm value. Can we either abandon and retire this differential, and I'll start a new one or can I commandeer this one and make all the other work subordanate to it?

[fabian.freyer_physik.tu-berlin.de]

@rgrimes, sure, go ahead, as you see fit.

[jhb]

Solved differently upstream.