[Devel] [PATCH hci-8.1 v2 0/2] mm: allow MADV_DOEXEC on VFIO BAR mappings

[Konstantin Khorenko]

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 are admitted by the same check. Andrey tested
qemu-update with an NVIDIA vGPU on his first version of patch 1; v2
calls ->open() and ->close() of the vGPU BAR mappings the way that
version did. Other out-of-tree drivers were not verified.

https://virtuozzo.atlassian.net/browse/VSTOR-150233

---
Changes in v2:
- Patch 1: do not refuse a VFIO mapping whose vm_ops has ->close() but
  no ->open(). The NVIDIA vGPU driver maps the BAR0 pieces of a vGPU
  that way, so in v1 qemu-update failed on them with EINVAL from
  madvise(MADV_DOEXEC) (reported by Andrey). The driver now gets
  ->close() for the original VMA and for the copy with no ->open() in
  between, a sequence QEMU's MADV_DONTFORK otherwise keeps from it.
- Patch 2: the VFIO case now also maps the BAR one page off its size
  alignment, so that the copy duplicates PTEs; the aligned mapping gets
  huge PFN entries, which the copy leaves to be faulted in again. Both
  cases exec a second time without the mark and check that the BAR is
  gone, so a copy that kept VM_EXEC_KEEP would fail them.
- Patch 2: a BAR that cannot be mapped is reported without a stale
  errno.
- Link to v1: http://lore.virtuozzo.com/20261014-b4-prep-khorenko-vstor-103860-4-doexec-vfio-bars-v1-0-7be6c4d68114@virtuozzo.com

---
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                        |  28 +++++--
 mm/memory.c                         |   2 +-
 mm/mmap.c                           |  53 ++++++++----
 tools/testing/selftests/mm/doexec.c | 157 +++++++++++++++++++++++++++++++++++-
 5 files changed, 227 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>