PVM is out-of-tree for the long haul: the 2024 LKML RFC was never followed by a v2, and KVM maintainers pushed back on carrying its shadow-paging burden. Plan for vendor-tree maintenance, not for a mainline merge.
| Tree | Role |
|---|---|
virt-pvm/linux, branch pvm-612 (Linux 6.12 LTS) |
primary upstream; still receives fixes |
| cocoonstack/linux-pvm | our mirror; kernel.pin points here |
OpenCloudOS-Kernel (Gitee), branch linux-6.6/released/cube-pvm |
Tencent’s production tree (CubeSandbox); second source of fixes |
virt-pvm/misc |
reference guest/host configs, vendored under configs/upstream/ |
Monthly, and immediately on a security issue in virt-pvm/linux:
pvm-612 for new commits and the issue tracker for security fixes
(e.g. the 2026-07 shadow-paging use-after-free backport).gh repo sync cocoonstack/linux-pvm --branch pvm-612.
pvm-612 is a rebase-maintained branch — if upstream force-pushed, sync
with --force and note it in the bump commit body.kernel.pin (KERNEL_COMMIT, and KERNEL_VERSION if the base
moved), push, let both workflows go green.vX.Y.Z; the release workflow rebuilds and attaches
artifacts.The config-assertion lists in guest/build.sh and host/build.sh are the
safety net for bumps: a renamed or dropped symbol fails the build instead of
shipping a silently degraded kernel.
virt-pvm is a small team and the branch history is rebase-based. If it
goes dormant, the fallback order is:
cube-pvm branch (6.6 LTS) for security
backports and cherry-pick into a cocoonstack branch of the mirror.vmlinux-pvm-amd64 directly (same boot
contract as its own kernel), or point its boot/ pipeline at the pin.