Page MenuHomeFreeBSD

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

Authored by rgrimes on Mar 21 2017, 12:42 AM.



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

[ } 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 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.

Diff Detail

rS FreeBSD src repository
Lint Skipped
Unit Tests Skipped

Event Timeline

rgrimes added a subscriber: rgrimes.

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

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?

rgrimes edited the test plan for this revision. (Show Details)
rgrimes added a reviewer: