[Devel] [PATCH hci-8.1 0/2] mm: allow MADV_DOEXEC on VFIO BAR mappings
Konstantin Khorenko
khorenko at virtuozzo.com
Wed Oct 14 20:13:59 MSK 2026
VSTOR-103860: keep the VFIO BAR mappings of a QEMU process across a
live-update exec, so the device keeps its MMIO mappings without a
re-mmap. Applies on top of "mm, exec: fix the MADV_DOEXEC code we carry
from Oracle" and needs patch 1 of "mm, binfmt_elf: two fixes also posted
to mainline" (the copy_huge_pmd() recheck), because every live-update
exec now copies the BAR's huge PMDs. The latter is posted as
http://lore.virtuozzo.com/20261014-b4-prep-khorenko-vstor-149847-1-upstream-fixes-v1-0-7fde9ffbebe9@virtuozzo.com
Patch 1 (Andrey, reworked) admits shared PFN mappings to MADV_DOEXEC
only for VFIO device files, checked with vfio_file_is_valid() through
symbol_get() as KVM does; other PFN maps (perf ring buffers, Xen
privcmd, /dev/mem) stay refused, as they would underflow pinned_vm or
free their memtype twice. The copy takes a file reference, keeps PAT
tracking, and write-locks the source VMA.
Patch 2 is the selftest: a real VFIO device bound to vfio-pci (the
DOEXEC_VFIO_DEVICE variable names it), plus the refused cases.
Tested on a KVM guest with the guest's QXL device bound to vfio-pci in
no-IOMMU mode, release and debug kernels.
Out-of-tree VFIO drivers (NVIDIA vGPU, mdev or SR-IOV variants) are
admitted by the same check but were not verified; see the ticket.
https://virtuozzo.atlassian.net/browse/VSTOR-150233
---
Andrey Drobyshev (1):
mm: allow MADV_DOEXEC on shared PFN mappings of device memory
Konstantin Khorenko (1):
selftests/mm: check MADV_DOEXEC on VFIO BARs and other PFN mappings
include/linux/mm.h | 12 ++-
mm/madvise.c | 30 ++++++--
mm/memory.c | 2 +-
mm/mmap.c | 53 ++++++++++----
tools/testing/selftests/mm/doexec.c | 141 +++++++++++++++++++++++++++++++++++-
5 files changed, 213 insertions(+), 25 deletions(-)
---
base-commit: 5e71073f26ce94dbc9e38e7b65920a46a8c431da
change-id: 20261014-b4-prep-khorenko-vstor-103860-4-doexec-vfio-bars-072e6b06f243
Best regards,
--
Konstantin Khorenko <khorenko at virtuozzo.com>
More information about the Devel
mailing list