From: Ani Sinha <anisinha@redhat.com>
To: "Alex Williamson" <alex@shazbot.org>,
"Cédric Le Goater" <clg@redhat.com>
Cc: vkuznets@redhat.com, kraxel@redhat.com, pbonzini@redhat.com,
qemu-devel@nongnu.org, Ani Sinha <anisinha@redhat.com>
Subject: [PATCH v1 19/28] hw/vfio: generate new file fd for pseudo device and rebind existing descriptors
Date: Fri, 12 Dec 2025 20:33:47 +0530 [thread overview]
Message-ID: <20251212150359.548787-20-anisinha@redhat.com> (raw)
In-Reply-To: <20251212150359.548787-1-anisinha@redhat.com>
Normally the vfio pseudo device file descriptor lives for the life of the VM.
However, when the kvm VM file descriptor changes, a new file descriptor
for the pseudo device needs to be generated against the new kvm VM descriptor.
Other existing vfio descriptors needs to be reattached to the new pseudo device
descriptor. This change performs the above steps.
Signed-off-by: Ani Sinha <anisinha@redhat.com>
---
hw/vfio/helpers.c | 81 +++++++++++++++++++++++++++++++++++++++++++++--
1 file changed, 78 insertions(+), 3 deletions(-)
diff --git a/hw/vfio/helpers.c b/hw/vfio/helpers.c
index 23d13e5db5..ad9e9c9ead 100644
--- a/hw/vfio/helpers.c
+++ b/hw/vfio/helpers.c
@@ -109,12 +109,66 @@ bool vfio_get_info_dma_avail(struct vfio_iommu_type1_info *info,
#ifdef CONFIG_KVM
/*
* We have a single VFIO pseudo device per KVM VM. Once created it lives
- * for the life of the VM. Closing the file descriptor only drops our
- * reference to it and the device's reference to kvm. Therefore once
- * initialized, this file descriptor is only released on QEMU exit and
+ * for the life of the VM except when the vm file descriptor changes for
+ * confidential virtual machines. In that case, the old file descriptor is
+ * closed and a new file descriptor is recreated. Closing the file descriptor
+ * only drops our reference to it and the device's reference to kvm.
+ * Therefore once initialized, this file descriptor is normally only released
+ * on QEMU exit (except for confidential VMs as stated above) and
* we'll re-use it should another vfio device be attached before then.
*/
int vfio_kvm_device_fd = -1;
+
+typedef struct KVMVfioFileFd {
+ int fd;
+ QLIST_ENTRY(KVMVfioFileFd) node;
+} KVMVfioFileFd;
+
+static QLIST_HEAD(, KVMVfioFileFd) kvm_vfio_file_fds =
+ QLIST_HEAD_INITIALIZER(kvm_vfio_file_fds);
+
+static int kvm_vfio_filefd_rebind(NotifierWithReturn *notifier, void *data,
+ Error **errp);
+static struct NotifierWithReturn kvm_vfio_vmfd_change_notifier = {
+ .notify = kvm_vfio_filefd_rebind,
+};
+
+static int kvm_vfio_filefd_rebind(NotifierWithReturn *notifier, void *data,
+ Error **errp)
+{
+ KVMVfioFileFd *file_fd;
+ int ret = 0;
+ struct kvm_device_attr attr = {
+ .group = KVM_DEV_VFIO_FILE,
+ .attr = KVM_DEV_VFIO_FILE_ADD,
+ };
+ struct kvm_create_device cd = {
+ .type = KVM_DEV_TYPE_VFIO,
+ };
+
+ if (kvm_vm_ioctl(kvm_state, KVM_CREATE_DEVICE, &cd)) {
+ error_setg_errno(errp, errno, "Failed to create KVM VFIO device");
+ return -errno;
+ }
+
+ if (vfio_kvm_device_fd) {
+ close(vfio_kvm_device_fd);
+ }
+
+ vfio_kvm_device_fd = cd.fd;
+
+ QLIST_FOREACH(file_fd, &kvm_vfio_file_fds, node) {
+ attr.addr = (uint64_t)(unsigned long)&file_fd->fd;
+ if (ioctl(vfio_kvm_device_fd, KVM_SET_DEVICE_ATTR, &attr)) {
+ error_setg_errno(errp, errno,
+ "Failed to add fd %d to KVM VFIO device",
+ file_fd->fd);
+ ret = -errno;
+ }
+ }
+ return ret;
+}
+
#endif
void vfio_kvm_device_close(void)
@@ -136,6 +190,7 @@ int vfio_kvm_device_add_fd(int fd, Error **errp)
.attr = KVM_DEV_VFIO_FILE_ADD,
.addr = (uint64_t)(unsigned long)&fd,
};
+ KVMVfioFileFd *file_fd;
if (!kvm_enabled()) {
return 0;
@@ -152,6 +207,11 @@ int vfio_kvm_device_add_fd(int fd, Error **errp)
}
vfio_kvm_device_fd = cd.fd;
+ /*
+ * If the vm file descriptor changes, add a notifier so that we can
+ * re-create the vfio_kvm_device_fd.
+ */
+ kvm_vmfd_add_change_notifier(&kvm_vfio_vmfd_change_notifier);
}
if (ioctl(vfio_kvm_device_fd, KVM_SET_DEVICE_ATTR, &attr)) {
@@ -159,6 +219,11 @@ int vfio_kvm_device_add_fd(int fd, Error **errp)
fd);
return -errno;
}
+
+ file_fd = g_malloc0(sizeof(*file_fd));
+ file_fd->fd = fd;
+ QLIST_INSERT_HEAD(&kvm_vfio_file_fds, file_fd, node);
+
#endif
return 0;
}
@@ -171,6 +236,7 @@ int vfio_kvm_device_del_fd(int fd, Error **errp)
.attr = KVM_DEV_VFIO_FILE_DEL,
.addr = (uint64_t)(unsigned long)&fd,
};
+ KVMVfioFileFd *file_fd;
if (vfio_kvm_device_fd < 0) {
error_setg(errp, "KVM VFIO device isn't created yet");
@@ -182,6 +248,15 @@ int vfio_kvm_device_del_fd(int fd, Error **errp)
"Failed to remove fd %d from KVM VFIO device", fd);
return -errno;
}
+
+ QLIST_FOREACH(file_fd, &kvm_vfio_file_fds, node) {
+ if (file_fd->fd == fd) {
+ QLIST_REMOVE(file_fd, node);
+ g_free(file_fd);
+ break;
+ }
+ }
+
#endif
return 0;
}
--
2.42.0
next prev parent reply other threads:[~2025-12-12 15:06 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-12-12 15:03 [PATCH v1 00/28] Introduce support for confidential guest reset Ani Sinha
2025-12-12 15:03 ` [PATCH v1 01/28] i386/kvm: avoid installing duplicate msr entries in msr_handlers Ani Sinha
2025-12-12 15:03 ` [PATCH v1 02/28] hw/accel: add a per-accelerator callback to change VM accelerator handle Ani Sinha
2025-12-12 15:03 ` [PATCH v1 03/28] system/physmem: add helper to reattach existing memory after KVM VM fd change Ani Sinha
2025-12-12 15:03 ` [PATCH v1 04/28] accel/kvm: add changes required to support KVM VM file descriptor change Ani Sinha
2025-12-12 15:03 ` [PATCH v1 05/28] accel/kvm: mark guest state as unprotected after vm " Ani Sinha
2025-12-12 15:03 ` [PATCH v1 06/28] accel/kvm: add a notifier to indicate KVM VM file descriptor has changed Ani Sinha
2025-12-12 15:03 ` [PATCH v1 07/28] kvm/i386: implement architecture support for kvm file descriptor change Ani Sinha
2025-12-12 15:03 ` [PATCH v1 08/28] hw/i386: refactor x86_bios_rom_init for reuse in confidential guest reset Ani Sinha
2025-12-12 15:03 ` [PATCH v1 09/28] kvm/i386: reload firmware for " Ani Sinha
2025-12-12 15:03 ` [PATCH v1 10/28] accel/kvm: Add notifier to inform that the KVM VM file fd is about to be changed Ani Sinha
2025-12-12 15:03 ` [PATCH v1 11/28] accel/kvm: rebind current VCPUs to the new KVM VM file descriptor upon reset Ani Sinha
2025-12-12 15:03 ` [PATCH v1 12/28] i386/tdx: refactor TDX firmware memory initialization code into a new function Ani Sinha
2025-12-12 15:03 ` [PATCH v1 13/28] i386/tdx: finalize TDX guest state upon reset Ani Sinha
2025-12-12 15:03 ` [PATCH v1 14/28] i386/tdx: add a pre-vmfd change notifier to reset tdx state Ani Sinha
2025-12-12 15:03 ` [PATCH v1 15/28] i386/sev: add migration blockers only once Ani Sinha
2025-12-12 15:03 ` [PATCH v1 16/28] i386/sev: add notifiers " Ani Sinha
2025-12-12 15:03 ` [PATCH v1 17/28] i386/sev: free existing launch update data and kernel hashes data on init Ani Sinha
2025-12-12 15:03 ` [PATCH v1 18/28] i386/sev: add support for confidential guest reset Ani Sinha
2025-12-12 15:03 ` Ani Sinha [this message]
2025-12-12 15:03 ` [PATCH v1 20/28] kvm/i8254: " Ani Sinha
2025-12-12 15:03 ` [PATCH v1 21/28] hw/hyperv/vmbus: " Ani Sinha
2025-12-12 15:03 ` [PATCH v1 22/28] accel/kvm: add a per-confidential class callback to unlock guest state Ani Sinha
2025-12-12 15:03 ` [PATCH v1 23/28] kvm/xen-emu: re-initialize capabilities during confidential guest reset Ani Sinha
2025-12-12 15:03 ` [PATCH v1 24/28] kvm/xen_evtchn: add support for " Ani Sinha
2025-12-12 15:03 ` [PATCH v1 25/28] ppc/openpic: create a new openpic device and reattach mem region on coco reset Ani Sinha
2025-12-12 15:03 ` [PATCH v1 26/28] kvm/vcpu: add notifiers to inform vcpu file descriptor change Ani Sinha
2025-12-12 15:03 ` [PATCH v1 27/28] kvm/i386/apic: set local apic after vcpu file descriptors changed Ani Sinha
2025-12-12 15:03 ` [PATCH v1 28/28] kvm/clock: add support for confidential guest reset Ani Sinha
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=20251212150359.548787-20-anisinha@redhat.com \
--to=anisinha@redhat.com \
--cc=alex@shazbot.org \
--cc=clg@redhat.com \
--cc=kraxel@redhat.com \
--cc=pbonzini@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=vkuznets@redhat.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;
as well as URLs for NNTP newsgroup(s).