OpenVZ / Virtuozzo kernel development (devel@openvz.org)
 help / color / mirror / Atom feed
From: Konstantin Khorenko <khorenko@virtuozzo.com>
To: Andrey Drobyshev <andrey.drobyshev@virtuozzo.com>,
	Vasileios Almpanis <vasileios.almpanis@virtuozzo.com>,
	Pavel Tikhomirov <ptikhomirov@virtuozzo.com>
Cc: devel@openvz.org
Subject: [Devel] [PATCH hci-8.1 0/2] mm: allow MADV_DOEXEC on VFIO BAR mappings
Date: Wed, 14 Oct 2026 19:13:59 +0200	[thread overview]
Message-ID: <20261014-b4-prep-khorenko-vstor-103860-4-doexec-vfio-bars-v1-0-7be6c4d68114@virtuozzo.com> (raw)

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@virtuozzo.com>

_______________________________________________
Devel mailing list
Devel@openvz.org
https://lists.openvz.org/mailman/listinfo/devel

             reply	other threads:[~2026-10-14 17:15 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-10-14 17:13 Konstantin Khorenko [this message]
2026-10-14 17:14 ` [Devel] [PATCH hci-8.1 1/2] mm: allow MADV_DOEXEC on shared PFN mappings of device memory Konstantin Khorenko
2026-10-16 12:57   ` Andrey Drobyshev
2026-10-14 17:14 ` [Devel] [PATCH hci-8.1 2/2] selftests/mm: check MADV_DOEXEC on VFIO BARs and other PFN mappings Konstantin Khorenko

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20261014-b4-prep-khorenko-vstor-103860-4-doexec-vfio-bars-v1-0-7be6c4d68114@virtuozzo.com \
    --to=khorenko@virtuozzo.com \
    --cc=andrey.drobyshev@virtuozzo.com \
    --cc=devel@openvz.org \
    --cc=ptikhomirov@virtuozzo.com \
    --cc=vasileios.almpanis@virtuozzo.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox