I've been running a KVM_CREATE_VM-elimination line on the fast-agent branch and want to upstream it.
Problem: at high fork churn, per-fork VM create/destroy dominates, each KVM_CREATE_VM pays mm_take_all_locks plus a PM-notifier registration on a global rwsem whose chain walk is O(live VMs). Mass termination and warm-fill decay measurably past ~10k live VMs.
A VmGroup owns one KVM VM and hands out seats (vcpu fd, kvm_run mapping, POSIX timer, arena GPA partition in one MAP_NORESERVE window) to pooled forks of one master. One KVM_CREATE_VM per B forks instead of per fork; zero memslot ops and zero mmaps in a live group's steady state; host VMAs flat at ~10k out to 100k members. Feature-gated (MachineOptions::vm_group), default off; the whole suite also passes with it forced on. Pooled members refuse remote/IPRE, SMP, hugepages, reset_to_new_master, foreign-range deletes.
11 commits, rebased onto current master. Proposed ladder:
- KVM_RUN failure classification by whether the timeout timer fired
- lazy per-fork kvm_run mapping + cpu_id → kvm_vcpu_id/guest_cpu_index split
- VmGroup core, x86-64 (4 commits: pooling, lifecycle/PTE-partition invariant, one host mapping per group, one memslot per group)
- ARM64 port (3 commits; the PTE-partition invariant stays AMD64-only)
One PR each, 3 before 4. Object here if the seats-in-one-struct-kvm direction is wrong before we open them.
I've been running a KVM_CREATE_VM-elimination line on the fast-agent branch and want to upstream it.
Problem: at high fork churn, per-fork VM create/destroy dominates, each KVM_CREATE_VM pays mm_take_all_locks plus a PM-notifier registration on a global rwsem whose chain walk is O(live VMs). Mass termination and warm-fill decay measurably past ~10k live VMs.
A VmGroup owns one KVM VM and hands out seats (vcpu fd, kvm_run mapping, POSIX timer, arena GPA partition in one MAP_NORESERVE window) to pooled forks of one master. One KVM_CREATE_VM per B forks instead of per fork; zero memslot ops and zero mmaps in a live group's steady state; host VMAs flat at ~10k out to 100k members. Feature-gated (MachineOptions::vm_group), default off; the whole suite also passes with it forced on. Pooled members refuse remote/IPRE, SMP, hugepages, reset_to_new_master, foreign-range deletes.
11 commits, rebased onto current master. Proposed ladder:
One PR each, 3 before 4. Object here if the seats-in-one-struct-kvm direction is wrong before we open them.