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.

Details

Reviewers
jhb
fabian.freyer_physik.tu-berlin.de
Group Reviewers
bhyve
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

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

Diff Detail

Repository
rS FreeBSD src repository
Lint
Lint Skipped
Unit
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 commandeered this revision.Feb 19 2019, 5:02 PM
rgrimes edited reviewers, added: fabian.freyer_physik.tu-berlin.de; removed: rgrimes.
rgrimes removed a reviewer: grehan.Feb 20 2019, 5:52 PM