public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Samiullah Khawaja <skhawaja@google.com>
To: Pranjal Shrivastava <praan@google.com>
Cc: David Woodhouse <dwmw2@infradead.org>,
	 Lu Baolu <baolu.lu@linux.intel.com>,
	Joerg Roedel <joro@8bytes.org>, Will Deacon <will@kernel.org>,
	 Jason Gunthorpe <jgg@ziepe.ca>, YiFei Zhu <zhuyifei@google.com>,
	 Robin Murphy <robin.murphy@arm.com>,
	Kevin Tian <kevin.tian@intel.com>,
	 Alex Williamson <alex@shazbot.org>,
	Shuah Khan <shuah@kernel.org>,
	iommu@lists.linux.dev,  linux-kernel@vger.kernel.org,
	kvm@vger.kernel.org, Saeed Mahameed <saeedm@nvidia.com>,
	 Adithya Jayachandran <ajayachandra@nvidia.com>,
	Parav Pandit <parav@nvidia.com>,
	 Leon Romanovsky <leonro@nvidia.com>,
	William Tu <witu@nvidia.com>,
	 Pratyush Yadav <pratyush@kernel.org>,
	Pasha Tatashin <pasha.tatashin@soleen.com>,
	 David Matlack <dmatlack@google.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	 Chris Li <chrisl@kernel.org>, Vipin Sharma <vipinsh@google.com>
Subject: Re: [PATCH 11/14] iommufd-lu: Persist iommu hardware pagetables for live update
Date: Wed, 25 Mar 2026 20:32:31 +0000	[thread overview]
Message-ID: <acRECIdaf4d4h8TD@google.com> (raw)
In-Reply-To: <acRA0Ir1gzgtZiEN@google.com>

On Wed, Mar 25, 2026 at 08:08:48PM +0000, Pranjal Shrivastava wrote:
>On Tue, Feb 03, 2026 at 10:09:45PM +0000, Samiullah Khawaja wrote:
>> From: YiFei Zhu <zhuyifei@google.com>
>>
>> The caller is expected to mark each HWPT to be preserved with an ioctl
>> call, with a token that will be used in restore. At preserve time, each
>> HWPT's domain is then called with iommu_domain_preserve to preserve the
>> iommu domain.
>>
>> The HWPTs containing dma mappings backed by unpreserved memory should
>> not be preserved. During preservation check if the mappings contained in
>> the HWPT being preserved are only file based and all the files are
>> preserved.
>>
>> The memfd file preservation check is not enough when preserving iommufd.
>> The memfd might have shrunk between the mapping and memfd preservation.
>> This means that if it shrunk some pages that are right now pinned due to
>> iommu mappings are not preserved with the memfd. Only allow iommufd
>> preservation when all the iopt_pages are file backed and the memory file
>> was seal sealed during mapping. This guarantees that all the pages that
>> were backing memfd when it was mapped are preserved.
>>
>> Once HWPT is preserved the iopt associated with the HWPT is made
>> immutable. Since the map and unmap ioctls operates directly on iopt,
>> which contains an array of domains, while each hwpt contains only one
>> domain. The logic then becomes that mapping and unmapping is prohibited
>> if any of the domains in an iopt belongs to a preserved hwpt. However,
>> tracing to the hwpt through the domain is a lot more tedious than
>> tracing through the ioas, so if an hwpt is preserved, hwpt->ioas->iopt
>> is made immutable.
>>
>> When undoing this (making the iopts mutable again), there's never
>> a need to make some iopts mutable and some kept immutable, since
>> the undo only happen on unpreserve and error path of preserve.
>> Simply iterate all the ioas and clear the immutability flag on all
>> their iopts.
>>
>> Signed-off-by: YiFei Zhu <zhuyifei@google.com>
>> Signed-off-by: Samiullah Khawaja <skhawaja@google.com>
>> ---
>>  drivers/iommu/iommufd/io_pagetable.c    |  17 ++
>>  drivers/iommu/iommufd/io_pagetable.h    |   1 +
>>  drivers/iommu/iommufd/iommufd_private.h |  25 ++
>>  drivers/iommu/iommufd/liveupdate.c      | 300 ++++++++++++++++++++++++
>>  drivers/iommu/iommufd/main.c            |  14 +-
>>  drivers/iommu/iommufd/pages.c           |   8 +
>>  include/linux/kho/abi/iommufd.h         |  39 +++
>>  7 files changed, 403 insertions(+), 1 deletion(-)
>>  create mode 100644 include/linux/kho/abi/iommufd.h
>>
>> diff --git a/drivers/iommu/iommufd/io_pagetable.c b/drivers/iommu/iommufd/io_pagetable.c
>> index 436992331111..43e8a2443793 100644
>> --- a/drivers/iommu/iommufd/io_pagetable.c
>> +++ b/drivers/iommu/iommufd/io_pagetable.c
>> @@ -270,6 +270,11 @@ static int iopt_alloc_area_pages(struct io_pagetable *iopt,
>>  	}
>>
>>  	down_write(&iopt->iova_rwsem);
>> +	if (iopt_lu_map_immutable(iopt)) {
>> +		rc = -EBUSY;
>> +		goto out_unlock;
>> +	}
>> +
>>  	if ((length & (iopt->iova_alignment - 1)) || !length) {
>>  		rc = -EINVAL;
>>  		goto out_unlock;
>> @@ -328,6 +333,7 @@ static void iopt_abort_area(struct iopt_area *area)
>>  		WARN_ON(area->pages);
>>  	if (area->iopt) {
>>  		down_write(&area->iopt->iova_rwsem);
>> +		WARN_ON(iopt_lu_map_immutable(area->iopt));
>>  		interval_tree_remove(&area->node, &area->iopt->area_itree);
>>  		up_write(&area->iopt->iova_rwsem);
>>  	}
>> @@ -755,6 +761,12 @@ static int iopt_unmap_iova_range(struct io_pagetable *iopt, unsigned long start,
>>  again:
>>  	down_read(&iopt->domains_rwsem);
>>  	down_write(&iopt->iova_rwsem);
>> +
>> +	if (iopt_lu_map_immutable(iopt)) {
>> +		rc = -EBUSY;
>> +		goto out_unlock_iova;
>> +	}
>> +
>>  	while ((area = iopt_area_iter_first(iopt, start, last))) {
>>  		unsigned long area_last = iopt_area_last_iova(area);
>>  		unsigned long area_first = iopt_area_iova(area);
>> @@ -1398,6 +1410,11 @@ int iopt_cut_iova(struct io_pagetable *iopt, unsigned long *iovas,
>>  	int i;
>>
>>  	down_write(&iopt->iova_rwsem);
>> +	if (iopt_lu_map_immutable(iopt)) {
>> +		up_write(&iopt->iova_rwsem);
>> +		return -EBUSY;
>> +	}
>> +
>>  	for (i = 0; i < num_iovas; i++) {
>>  		struct iopt_area *area;
>>
>> diff --git a/drivers/iommu/iommufd/io_pagetable.h b/drivers/iommu/iommufd/io_pagetable.h
>> index 14cd052fd320..b64cb4cf300c 100644
>> --- a/drivers/iommu/iommufd/io_pagetable.h
>> +++ b/drivers/iommu/iommufd/io_pagetable.h
>> @@ -234,6 +234,7 @@ struct iopt_pages {
>>  		struct {			/* IOPT_ADDRESS_FILE */
>>  			struct file *file;
>>  			unsigned long start;
>> +			u32 seals;
>>  		};
>>  		/* IOPT_ADDRESS_DMABUF */
>>  		struct iopt_pages_dmabuf dmabuf;
>> diff --git a/drivers/iommu/iommufd/iommufd_private.h b/drivers/iommu/iommufd/iommufd_private.h
>> index 6424e7cea5b2..f8366a23999f 100644
>> --- a/drivers/iommu/iommufd/iommufd_private.h
>> +++ b/drivers/iommu/iommufd/iommufd_private.h
>> @@ -94,6 +94,9 @@ struct io_pagetable {
>>  	/* IOVA that cannot be allocated, struct iopt_reserved */
>>  	struct rb_root_cached reserved_itree;
>>  	u8 disable_large_pages;
>> +#ifdef CONFIG_IOMMU_LIVEUPDATE
>> +	bool lu_map_immutable;
>> +#endif
>>  	unsigned long iova_alignment;
>>  };
>>
>> @@ -712,12 +715,34 @@ iommufd_get_vdevice(struct iommufd_ctx *ictx, u32 id)
>>  }
>>
>>  #ifdef CONFIG_IOMMU_LIVEUPDATE
>> +int iommufd_liveupdate_register_lufs(void);
>> +int iommufd_liveupdate_unregister_lufs(void);
>> +
>>  int iommufd_hwpt_lu_set_preserve(struct iommufd_ucmd *ucmd);
>> +static inline bool iopt_lu_map_immutable(const struct io_pagetable *iopt)
>> +{
>> +	return iopt->lu_map_immutable;
>> +}
>>  #else
>> +static inline int iommufd_liveupdate_register_lufs(void)
>> +{
>> +	return 0;
>> +}
>> +
>> +static inline int iommufd_liveupdate_unregister_lufs(void)
>> +{
>> +	return 0;
>> +}
>> +
>>  static inline int iommufd_hwpt_lu_set_preserve(struct iommufd_ucmd *ucmd)
>>  {
>>  	return -ENOTTY;
>>  }
>> +
>> +static inline bool iopt_lu_map_immutable(const struct io_pagetable *iopt)
>> +{
>> +	return false;
>> +}
>>  #endif
>>
>>  #ifdef CONFIG_IOMMUFD_TEST
>> diff --git a/drivers/iommu/iommufd/liveupdate.c b/drivers/iommu/iommufd/liveupdate.c
>> index ae74f5b54735..ec11ae345fe7 100644
>> --- a/drivers/iommu/iommufd/liveupdate.c
>> +++ b/drivers/iommu/iommufd/liveupdate.c
>> @@ -4,9 +4,15 @@
>>
>>  #include <linux/file.h>
>>  #include <linux/iommufd.h>
>> +#include <linux/kexec_handover.h>
>> +#include <linux/kho/abi/iommufd.h>
>>  #include <linux/liveupdate.h>
>> +#include <linux/iommu-lu.h>
>> +#include <linux/mm.h>
>> +#include <linux/pci.h>
>>
>>  #include "iommufd_private.h"
>> +#include "io_pagetable.h"
>>
>>  int iommufd_hwpt_lu_set_preserve(struct iommufd_ucmd *ucmd)
>>  {
>> @@ -47,3 +53,297 @@ int iommufd_hwpt_lu_set_preserve(struct iommufd_ucmd *ucmd)
>>  	return rc;
>>  }
>>
>> +static void iommufd_set_ioas_mutable(struct iommufd_ctx *ictx)
>> +{
>> +	struct iommufd_object *obj;
>> +	struct iommufd_ioas *ioas;
>> +	unsigned long index;
>> +
>> +	xa_lock(&ictx->objects);
>> +	xa_for_each(&ictx->objects, index, obj) {
>> +		if (obj->type != IOMMUFD_OBJ_IOAS)
>> +			continue;
>> +
>> +		ioas = container_of(obj, struct iommufd_ioas, obj);
>> +
>> +		/*
>> +		 * Not taking any IOAS lock here. All writers take LUO
>> +		 * session mutex, and this writer racing with readers is not
>> +		 * really a problem.
>> +		 */
>> +		WRITE_ONCE(ioas->iopt.lu_map_immutable, false);
>> +	}
>> +	xa_unlock(&ictx->objects);
>> +}
>> +
>> +static int check_iopt_pages_preserved(struct liveupdate_session *s,
>> +				      struct iommufd_hwpt_paging *hwpt)
>> +{
>> +	u32 req_seals = F_SEAL_SEAL | F_SEAL_GROW | F_SEAL_SHRINK;
>> +	struct iopt_area *area;
>> +	int ret;
>> +
>> +	for (area = iopt_area_iter_first(&hwpt->ioas->iopt, 0, ULONG_MAX); area;
>> +	     area = iopt_area_iter_next(area, 0, ULONG_MAX)) {
>> +		struct iopt_pages *pages = area->pages;
>> +
>> +		/* Only allow file based mapping */
>> +		if (pages->type != IOPT_ADDRESS_FILE)
>> +			return -EINVAL;
>
>That's an important check! should we document it somewhere for the user
>to know about it too? Perhaps in the uAPI header for the preserve IOCTL,
>so VMM authors are aware of the anonymous memory restriction upfront?

Agreed. Will add this in next revision.
>
>> +
>> +		/*
>> +		 * When this memory file was mapped it should be sealed and seal
>> +		 * should be sealed. This means that since mapping was done the
>> +		 * memory file was not grown or shrink and the pages being used
>> +		 * until now remain pinnned and preserved.
>> +		 */
>> +		if ((pages->seals & req_seals) != req_seals)
>> +			return -EINVAL;
>> +
>> +		/* Make sure that the file was preserved. */
>> +		ret = liveupdate_get_token_outgoing(s, pages->file, NULL);
>> +		if (ret)
>> +			return ret;
>> +	}
>> +
>> +	return 0;
>> +}
>> +
>> +static int iommufd_save_hwpts(struct iommufd_ctx *ictx,
>> +			      struct iommufd_lu *iommufd_lu,
>> +			      struct liveupdate_session *session)
>> +{
>> +	struct iommufd_hwpt_paging *hwpt, **hwpts = NULL;
>> +	struct iommu_domain_ser *domain_ser;
>> +	struct iommufd_hwpt_lu *hwpt_lu;
>> +	struct iommufd_object *obj;
>> +	unsigned int nr_hwpts = 0;
>> +	unsigned long index;
>> +	unsigned int i;
>> +	int rc = 0;
>> +
>> +	if (iommufd_lu) {
>> +		hwpts = kcalloc(iommufd_lu->nr_hwpts, sizeof(*hwpts),
>> +				GFP_KERNEL);
>> +		if (!hwpts)
>> +			return -ENOMEM;
>> +	}
>> +
>> +	xa_lock(&ictx->objects);
>> +	xa_for_each(&ictx->objects, index, obj) {
>> +		if (obj->type != IOMMUFD_OBJ_HWPT_PAGING)
>> +			continue;
>> +
>> +		hwpt = container_of(obj, struct iommufd_hwpt_paging, common.obj);
>> +		if (!hwpt->lu_preserve)
>> +			continue;
>> +
>> +		if (hwpt->ioas) {
>> +			/*
>> +			 * Obtain exclusive access to the IOAS and IOPT while we
>> +			 * set immutability
>> +			 */
>> +			mutex_lock(&hwpt->ioas->mutex);
>
>Doubling down on Ankit's comment here, we should absolutely avoid taking
>sleepable locks in atomic context. I can attempt testing the next series
>with lockdep enabled.
>
>> +			down_write(&hwpt->ioas->iopt.domains_rwsem);
>> +			down_write(&hwpt->ioas->iopt.iova_rwsem);
>> +
>> +			hwpt->ioas->iopt.lu_map_immutable = true;
>> +
>> +			up_write(&hwpt->ioas->iopt.iova_rwsem);
>> +			up_write(&hwpt->ioas->iopt.domains_rwsem);
>> +			mutex_unlock(&hwpt->ioas->mutex);
>
>Additionally, I'm wondering if this could be a helper function?
>iommufd_ioas_set_immutable?

I will have to restructure this part of the code to not take the mutex
in the atomic context. I will move it to a helper function in next
revision if there is opportunity to do that.
>
>> +		}
>> +
>> +		if (!hwpt->common.domain) {
>> +			rc = -EINVAL;
>> +			xa_unlock(&ictx->objects);
>> +			goto out;
>> +		}
>> +
>> +		if (!iommufd_lu) {
>> +			rc = check_iopt_pages_preserved(session, hwpt);
>
>This seems slightly redundant, we are calling check_iopt_pages_preserved
>for every single preserved HWPT. However, multiple HWPTs can share the
>same underlying IOAS.

Agreed. I think this check and the earlier immutable thing need to be
done at IOPT level. I think the rework for that should also remove the
redundant checks here.
>
>If a VMM has 5 devices sharing a single IOAS, this code will walk the
>exact same iopt_area_itree and validate the exact same memfd seals 5
>times. Should we perhaps track which iopts have already been validated
>during the loop to avoid this redundant tree traversal?
>
>> +			if (rc) {
>> +				xa_unlock(&ictx->objects);
>> +				goto out;
>> +			}
>> +		} else if (iommufd_lu) {
>> +			hwpts[nr_hwpts] = hwpt;
>> +			hwpt_lu = &iommufd_lu->hwpts[nr_hwpts];
>> +
>> +			hwpt_lu->token = hwpt->lu_token;
>> +			hwpt_lu->reclaimed = false;
>> +		}
>> +
>> +		nr_hwpts++;
>> +	}
>> +	xa_unlock(&ictx->objects);
>> +
>> +	if (WARN_ON(iommufd_lu && iommufd_lu->nr_hwpts != nr_hwpts)) {
>> +		rc = -EFAULT;
>> +		goto out;
>> +	}
>> +
>> +	if (iommufd_lu) {
>> +		/*
>> +		 * iommu_domain_preserve may sleep and must be called
>> +		 * outside of xa_lock
>> +		 */
>> +		for (i = 0; i < nr_hwpts; i++) {
>> +			hwpt = hwpts[i];
>> +			hwpt_lu = &iommufd_lu->hwpts[i];
>> +
>> +			rc = iommu_domain_preserve(hwpt->common.domain, &domain_ser);
>> +			if (rc < 0)
>> +				goto out;
>> +
>> +			hwpt_lu->domain_data = __pa(domain_ser);
>> +		}
>> +	}
>> +
>> +	rc = nr_hwpts;
>> +
>> +out:
>> +	kfree(hwpts);
>> +	return rc;
>> +}
>> +
>> +static int iommufd_liveupdate_preserve(struct liveupdate_file_op_args *args)
>> +{
>> +	struct iommufd_ctx *ictx = iommufd_ctx_from_file(args->file);
>> +	struct iommufd_lu *iommufd_lu;
>> +	size_t serial_size;
>> +	void *mem;
>> +	int rc;
>> +
>> +	if (IS_ERR(ictx))
>> +		return PTR_ERR(ictx);
>> +
>> +	rc = iommufd_save_hwpts(ictx, NULL, args->session);
>> +	if (rc < 0)
>> +		goto err_ioas_mutable;
>> +
>> +	serial_size = struct_size(iommufd_lu, hwpts, rc);
>> +
>> +	mem = kho_alloc_preserve(serial_size);
>> +	if (!mem) {
>> +		rc = -ENOMEM;
>> +		goto err_ioas_mutable;
>> +	}
>> +
>> +	iommufd_lu = mem;
>> +	iommufd_lu->nr_hwpts = rc;
>> +	rc = iommufd_save_hwpts(ictx, iommufd_lu, args->session);
>
>We call iommufd_save_hwpts twice (first to count/validate & second to
>serialize). Because xa_lock is dropped between these two calls to
>allocate KHO memory, we have a TOCTOU race.

Agreed. Will handle this in next revision.
>
>If userspace concurrently creates or destroys a preserved HWPT during
>this window, nr_hwpts will change, and the second pass will hit:
>WARN_ON(iommufd_lu && iommufd_lu->nr_hwpts != nr_hwpts)
>
>I'm not sure if that's a situation to WARN? Also, what about kernels
>which have panic_on_warn?
>
>> +	if (rc < 0)
>> +		goto err_free;
>> +
>> +	args->serialized_data = virt_to_phys(iommufd_lu);
>> +	iommufd_ctx_put(ictx);
>> +	return 0;
>> +
>> +err_free:
>> +	kho_unpreserve_free(mem);
>> +err_ioas_mutable:
>> +	iommufd_set_ioas_mutable(ictx);
>> +	iommufd_ctx_put(ictx);
>> +	return rc;
>> +}
>> +
>> +static int iommufd_liveupdate_freeze(struct liveupdate_file_op_args *args)
>> +{
>> +	/* No-Op; everything should be made read-only */
>
>Is there a plan to populate this in a future series? If it's a permanent
>No-Op because the lu_map_immutable flag already handles the read-only
>enforcement during the preserve phase, we should probably update the
>comment to explicitly state that, rather than implying there is missing
>logic?

Agreed. Will update the comment.
>
>> +	return 0;
>> +}
>> +
>
>[ ---- >8 ----- ]
>
>> diff --git a/include/linux/kho/abi/iommufd.h b/include/linux/kho/abi/iommufd.h
>> new file mode 100644
>> index 000000000000..f7393ac78aa9
>> --- /dev/null
>> +++ b/include/linux/kho/abi/iommufd.h
>> @@ -0,0 +1,39 @@
>> +/* SPDX-License-Identifier: GPL-2.0 */
>> +
>> +/*
>> + * Copyright (C) 2025, Google LLC
>> + * Author: Samiullah Khawaja <skhawaja@google.com>
>> + */
>> +
>> +#ifndef _LINUX_KHO_ABI_IOMMUFD_H
>> +#define _LINUX_KHO_ABI_IOMMUFD_H
>> +
>> +#include <linux/mutex_types.h>
>> +#include <linux/compiler.h>
>> +#include <linux/types.h>
>> +
>> +/**
>> + * DOC: IOMMUFD Live Update ABI
>> + *
>> + * This header defines the ABI for preserving the state of an IOMMUFD file
>> + * across a kexec reboot using LUO.
>> + *
>> + * This interface is a contract. Any modification to any of the serialization
>> + * structs defined here constitutes a breaking change. Such changes require
>> + * incrementing the version number in the IOMMUFD_LUO_COMPATIBLE string.
>> + */
>> +
>> +#define IOMMUFD_LUO_COMPATIBLE "iommufd-v1"
>> +
>> +struct iommufd_hwpt_lu {
>> +	u32 token;
>> +	u64 domain_data;
>> +	bool reclaimed;
>> +} __packed;
>> +
>
>Nit: Because of __packed, putting the u64 after the u32 forces an
>unaligned 8-byte access at offset 4. Also, it's generally safer to use
>explicitly sized types like u8 instead of bool for cross-kernel ABI
>structs to avoid any compiler-specific sizing ambiguities. (This is the
>reason most uAPI defs avoid using bool)
>
>We can achieve natural alignment without implicit padding by ordering it
>from largest to smallest and explicitly padding it out:
>
>struct iommufd_hwpt_lu {
>	__u64 domain_data;
>	__u32 token;
>	__u8 reclaimed;
>	__u8 padding[3];
>} __packed;
>
>This guarantees an exact 16-byte footprint with perfectly aligned 64-bit
>and 32-bit accesses.
>
>> +struct iommufd_lu {
>> +	unsigned int nr_hwpts;
>> +	struct iommufd_hwpt_lu hwpts[];
>> +};
>
>Same here regarding explicitly sized types and packing (as pointed by
>Vipin too)
>
>> +
>> +#endif /* _LINUX_KHO_ABI_IOMMUFD_H */
>
>Thanks,
>Praan

  reply	other threads:[~2026-03-25 20:32 UTC|newest]

Thread overview: 98+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-02-03 22:09 [PATCH 00/14] iommu: Add live update state preservation Samiullah Khawaja
2026-02-03 22:09 ` [PATCH 01/14] iommu: Implement IOMMU LU FLB callbacks Samiullah Khawaja
2026-03-11 21:07   ` Pranjal Shrivastava
2026-03-12 16:43     ` Samiullah Khawaja
2026-03-12 23:43       ` Pranjal Shrivastava
2026-03-13 16:47         ` Samiullah Khawaja
2026-03-13 15:36       ` Pranjal Shrivastava
2026-03-13 16:58         ` Samiullah Khawaja
2026-03-16 22:54   ` Vipin Sharma
2026-03-17  1:06     ` Samiullah Khawaja
2026-03-23 23:27       ` Vipin Sharma
2026-02-03 22:09 ` [PATCH 02/14] iommu: Implement IOMMU core liveupdate skeleton Samiullah Khawaja
2026-03-12 23:10   ` Pranjal Shrivastava
2026-03-13 18:42     ` Samiullah Khawaja
2026-03-17 20:09       ` Pranjal Shrivastava
2026-03-17 20:13         ` Samiullah Khawaja
2026-03-17 20:23           ` Pranjal Shrivastava
2026-03-17 21:03             ` Vipin Sharma
2026-03-18 18:51               ` Pranjal Shrivastava
2026-03-18 17:49             ` Samiullah Khawaja
2026-03-17 19:58   ` Vipin Sharma
2026-03-17 20:33     ` Samiullah Khawaja
2026-03-24 19:06       ` Vipin Sharma
2026-03-24 19:45         ` Samiullah Khawaja
2026-02-03 22:09 ` [PATCH 03/14] liveupdate: luo_file: Add internal APIs for file preservation Samiullah Khawaja
2026-03-18 10:00   ` Pranjal Shrivastava
2026-03-18 16:54     ` Samiullah Khawaja
2026-02-03 22:09 ` [PATCH 04/14] iommu/pages: Add APIs to preserve/unpreserve/restore iommu pages Samiullah Khawaja
2026-03-03 16:42   ` Ankit Soni
2026-03-03 18:41     ` Samiullah Khawaja
2026-03-20 17:27       ` Pranjal Shrivastava
2026-03-20 18:12         ` Samiullah Khawaja
2026-03-17 20:59   ` Vipin Sharma
2026-03-20  9:28     ` Pranjal Shrivastava
2026-03-20 18:27       ` Samiullah Khawaja
2026-03-20 11:01     ` Pranjal Shrivastava
2026-03-20 18:56       ` Samiullah Khawaja
2026-02-03 22:09 ` [PATCH 05/14] iommupt: Implement preserve/unpreserve/restore callbacks Samiullah Khawaja
2026-03-20 21:57   ` Pranjal Shrivastava
2026-03-23 16:41     ` Samiullah Khawaja
2026-02-03 22:09 ` [PATCH 06/14] iommu/vt-d: Implement device and iommu preserve/unpreserve ops Samiullah Khawaja
2026-03-19 16:04   ` Vipin Sharma
2026-03-19 16:27     ` Samiullah Khawaja
2026-03-20 23:01   ` Pranjal Shrivastava
2026-03-21 13:27     ` Pranjal Shrivastava
2026-03-23 18:32     ` Samiullah Khawaja
2026-02-03 22:09 ` [PATCH 07/14] iommu/vt-d: Restore IOMMU state and reclaimed domain ids Samiullah Khawaja
2026-03-19 20:54   ` Vipin Sharma
2026-03-20  1:05     ` Samiullah Khawaja
2026-03-22 19:51   ` Pranjal Shrivastava
2026-03-23 19:33     ` Samiullah Khawaja
2026-02-03 22:09 ` [PATCH 08/14] iommu: Restore and reattach preserved domains to devices Samiullah Khawaja
2026-03-10  5:16   ` Ankit Soni
2026-03-10 21:47     ` Samiullah Khawaja
2026-03-22 21:59   ` Pranjal Shrivastava
2026-03-23 18:02     ` Samiullah Khawaja
2026-02-03 22:09 ` [PATCH 09/14] iommu/vt-d: preserve PASID table of preserved device Samiullah Khawaja
2026-03-23 18:19   ` Pranjal Shrivastava
2026-03-23 18:51     ` Samiullah Khawaja
2026-02-03 22:09 ` [PATCH 10/14] iommufd-lu: Implement ioctl to let userspace mark an HWPT to be preserved Samiullah Khawaja
2026-03-19 23:35   ` Vipin Sharma
2026-03-20  0:40     ` Samiullah Khawaja
2026-03-20 23:34       ` Vipin Sharma
2026-03-23 16:24         ` Samiullah Khawaja
2026-03-25 14:37   ` Pranjal Shrivastava
2026-03-25 17:31     ` Samiullah Khawaja
2026-03-25 18:55       ` Pranjal Shrivastava
2026-03-25 20:19         ` Samiullah Khawaja
2026-03-25 20:36           ` Pranjal Shrivastava
2026-03-25 20:46             ` Samiullah Khawaja
2026-02-03 22:09 ` [PATCH 11/14] iommufd-lu: Persist iommu hardware pagetables for live update Samiullah Khawaja
2026-02-25 23:47   ` Samiullah Khawaja
2026-03-03  5:56   ` Ankit Soni
2026-03-03 18:51     ` Samiullah Khawaja
2026-03-23 20:28   ` Vipin Sharma
2026-03-23 21:34     ` Samiullah Khawaja
2026-03-25 20:08   ` Pranjal Shrivastava
2026-03-25 20:32     ` Samiullah Khawaja [this message]
2026-02-03 22:09 ` [PATCH 12/14] iommufd: Add APIs to preserve/unpreserve a vfio cdev Samiullah Khawaja
2026-03-23 20:59   ` Vipin Sharma
2026-03-23 21:38     ` Samiullah Khawaja
2026-03-25 20:24   ` Pranjal Shrivastava
2026-03-25 20:41     ` Samiullah Khawaja
2026-03-25 21:23       ` Pranjal Shrivastava
2026-03-26  0:16         ` Samiullah Khawaja
2026-02-03 22:09 ` [PATCH 13/14] vfio/pci: Preserve the iommufd state of the " Samiullah Khawaja
2026-02-17  4:18   ` Ankit Soni
2026-03-03 18:35     ` Samiullah Khawaja
2026-03-23 21:17   ` Vipin Sharma
2026-03-23 22:07     ` Samiullah Khawaja
2026-03-24 20:30       ` Vipin Sharma
2026-03-25 20:55   ` Pranjal Shrivastava
2026-02-03 22:09 ` [PATCH 14/14] iommufd/selftest: Add test to verify iommufd preservation Samiullah Khawaja
2026-03-23 22:18   ` Vipin Sharma
2026-03-27 18:32     ` Samiullah Khawaja
2026-03-25 21:05   ` Pranjal Shrivastava
2026-03-27 18:25     ` Samiullah Khawaja
2026-03-27 18:40       ` Samiullah Khawaja

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=acRECIdaf4d4h8TD@google.com \
    --to=skhawaja@google.com \
    --cc=ajayachandra@nvidia.com \
    --cc=akpm@linux-foundation.org \
    --cc=alex@shazbot.org \
    --cc=baolu.lu@linux.intel.com \
    --cc=chrisl@kernel.org \
    --cc=dmatlack@google.com \
    --cc=dwmw2@infradead.org \
    --cc=iommu@lists.linux.dev \
    --cc=jgg@ziepe.ca \
    --cc=joro@8bytes.org \
    --cc=kevin.tian@intel.com \
    --cc=kvm@vger.kernel.org \
    --cc=leonro@nvidia.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=parav@nvidia.com \
    --cc=pasha.tatashin@soleen.com \
    --cc=praan@google.com \
    --cc=pratyush@kernel.org \
    --cc=robin.murphy@arm.com \
    --cc=saeedm@nvidia.com \
    --cc=shuah@kernel.org \
    --cc=vipinsh@google.com \
    --cc=will@kernel.org \
    --cc=witu@nvidia.com \
    --cc=zhuyifei@google.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