From: David Matlack <dmatlack@google.com>
To: Samiullah Khawaja <skhawaja@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>,
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>,
Andrew Morton <akpm@linux-foundation.org>,
Chris Li <chrisl@kernel.org>,
Pranjal Shrivastava <praan@google.com>,
Vipin Sharma <vipinsh@google.com>,
YiFei Zhu <zhuyifei@google.com>
Subject: Re: [PATCH v2 02/16] iommu: Implement IOMMU Live update FLB callbacks
Date: Fri, 1 May 2026 21:45:19 +0000 [thread overview]
Message-ID: <afUe71D8JfgmA0BG@google.com> (raw)
In-Reply-To: <20260427175633.1978233-3-skhawaja@google.com>
On 2026-04-27 05:56 PM, Samiullah Khawaja wrote:
> Add liveupdate FLB for IOMMU state preservation. Use KHO preserve memory
> alloc/free helper functions to allocate memory for the IOMMU Live update
> FLB object and the serialization structs for device, domain and iommu.
>
> During retrieve, walk through the preserved obj array headers and
> restore each folio. Also recreate the FLB obj.
>
> Signed-off-by: Samiullah Khawaja <skhawaja@google.com>
> +static void *iommu_liveupdate_restore_array(u64 array_phys)
> +{
> + struct iommu_array_hdr_ser *array_hdr;
> + void *vaddr = array_phys ? phys_to_virt(array_phys) : NULL;
> +
> + while (array_phys) {
> + /*
> + * Failure to restore preserved IOMMU state is considered fatal.
> + *
> + * This is because the IOMMU translations for preserved IOMMUs
> + * were kept enabled in the previous kernel and the preserved
> + * devices have their IOMMU domains still present. Not being
> + * able to restore means that the memory mapped into preserved
> + * domains might be already corrupted by the preserved devices.
> + *
> + * There is no way to confirm the integrity of the memory that
> + * was mapped. BUG_ON is the safest option at this point.
> + */
> + BUG_ON(!kho_restore_folio(array_phys));
> + array_hdr = phys_to_virt(array_phys);
> + array_phys = array_hdr->next_array_phys;
> + }
> +
> + return vaddr;
> +}
> +static int iommu_liveupdate_flb_retrieve(struct liveupdate_flb_op_args *argp)
> +{
> + struct iommu_flb_obj *obj;
> + struct iommu_flb_ser *ser;
> +
> + obj = kzalloc_obj(*obj, GFP_KERNEL);
> + if (!obj)
> + return -ENOMEM;
Should this be considered fatal for the same reason
iommu_liveupdate_restore_array() is considered fatal? If anything in
iommu_liveupdate_flb_retrieve() fails then the risk of corruption as
described in iommu_liveupdate_restore_array() is possible.
> +
> + /* Data must be present and valid from the previous kernel */
> + BUG_ON(!kho_restore_folio(argp->data));
> +
> + mutex_init(&obj->lock);
> + ser = phys_to_virt(argp->data);
> + obj->ser = ser;
> +
> + obj->curr_domain_array = iommu_liveupdate_restore_array(ser->iommu_domain_array_phys);
> + obj->curr_device_array = iommu_liveupdate_restore_array(ser->device_array_phys);
> + obj->curr_iommu_array = iommu_liveupdate_restore_array(ser->iommu_array_phys);
> + argp->obj = obj;
> + return 0;
> +}
> +
> +static struct liveupdate_flb_ops iommu_flb_ops = {
> + .preserve = iommu_liveupdate_flb_preserve,
> + .unpreserve = iommu_liveupdate_flb_unpreserve,
> + .finish = iommu_liveupdate_flb_finish,
> + .retrieve = iommu_liveupdate_flb_retrieve,
nit: I think it's helpful to put these in the order they are expected to
be called.
.preserve = iommu_liveupdate_flb_preserve,
.unpreserve = iommu_liveupdate_flb_unpreserve,
.retrieve = iommu_liveupdate_flb_retrieve,
.finish = iommu_liveupdate_flb_finish,
> diff --git a/include/linux/kho/abi/iommu.h b/include/linux/kho/abi/iommu.h
> new file mode 100644
> index 000000000000..37b967820f14
> +enum iommu_type_ser {
> + IOMMU_INVALID,
> +};
Please document this enum.
> +
> +/**
> + * struct iommu_hdr_ser - Common header for all serialized IOMMU objects
> + * @ref_count: Reference count for the object
> + * @deleted: Flag indicating if the object is deleted
> + * @incoming: Flag indicating if the object was preserved in previous kernel
> + */
> +struct iommu_hdr_ser {
> + u32 ref_count;
> + u32 deleted:1;
> + u32 incoming:1;
Are C bitfields safe to use in Live Update ABI?
> +} __packed;
> +/**
> + * struct iommu_flb_obj - FLB object allocated in current kernel pointing to
> + * preserved state in FLB
> + * @lock: Mutex protecting the object
> + * @ser: Pointer to the serialized state in FLB
> + * @curr_iommu_array: Pointer to the current array of IOMMU instances
> + * @curr_domain_array: Pointer to the current array of domains
> + * @curr_device_array: Pointer to the current array of devices
> + */
> +struct iommu_flb_obj {
> + /* @lock: Protects the serialized objects during concurrent preservation */
> + struct mutex lock;
> + struct iommu_flb_ser *ser;
> +
> + struct iommu_hw_array_ser *curr_iommu_array;
> + struct iommu_domain_array_ser *curr_domain_array;
> + struct iommu_device_array_ser *curr_device_array;
> +} __packed;
This struct is not ABI so it should not be __packed nor defined in this
file. I haven't read the whole series yet but this definition can
probably go in drivers/iommu/liveupdate.c.
next prev parent reply other threads:[~2026-05-01 21:45 UTC|newest]
Thread overview: 35+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-04-27 17:56 [PATCH v2 00/16] iommu: Add live update state preservation Samiullah Khawaja
2026-04-27 17:56 ` [PATCH v2 01/16] liveupdate: luo_file: Add internal APIs for file preservation Samiullah Khawaja
2026-04-27 17:56 ` [PATCH v2 02/16] iommu: Implement IOMMU Live update FLB callbacks Samiullah Khawaja
2026-05-01 21:45 ` David Matlack [this message]
2026-04-27 17:56 ` [PATCH v2 03/16] iommu: Implement IOMMU domain preservation Samiullah Khawaja
2026-05-01 22:08 ` David Matlack
2026-05-04 18:33 ` Samiullah Khawaja
2026-04-27 17:56 ` [PATCH v2 04/16] iommu: Implement device and IOMMU HW preservation Samiullah Khawaja
2026-05-01 22:42 ` David Matlack
2026-05-04 19:06 ` Samiullah Khawaja
2026-05-07 2:07 ` Baolu Lu
2026-05-07 18:47 ` Samiullah Khawaja
2026-04-27 17:56 ` [PATCH v2 05/16] iommu/pages: Add APIs to preserve/unpreserve/restore iommu pages Samiullah Khawaja
2026-04-27 17:56 ` [PATCH v2 06/16] iommupt: Implement preserve/unpreserve/restore callbacks Samiullah Khawaja
2026-05-07 2:55 ` Baolu Lu
2026-05-07 18:40 ` Samiullah Khawaja
2026-04-27 17:56 ` [PATCH v2 07/16] iommu/vt-d: Implement device and iommu preserve/unpreserve ops Samiullah Khawaja
2026-05-07 6:25 ` Baolu Lu
2026-05-08 2:36 ` Samiullah Khawaja
2026-04-27 17:56 ` [PATCH v2 08/16] iommu: Add APIs to get iommu and device preserved state Samiullah Khawaja
2026-04-27 17:56 ` [PATCH v2 09/16] iommu/vt-d: Restore IOMMU state and reclaimed domain ids Samiullah Khawaja
2026-05-07 9:05 ` Baolu Lu
2026-05-07 17:35 ` Samiullah Khawaja
2026-04-27 17:56 ` [PATCH v2 10/16] iommu: Restore and reattach preserved domains to devices Samiullah Khawaja
2026-05-07 13:54 ` Baolu Lu
2026-05-07 16:52 ` Samiullah Khawaja
2026-04-27 17:56 ` [PATCH v2 11/16] iommu/vt-d: preserve PASID table of preserved device Samiullah Khawaja
2026-05-08 6:05 ` Baolu Lu
2026-05-11 18:45 ` Samiullah Khawaja
2026-05-12 11:32 ` Baolu Lu
2026-04-27 17:56 ` [PATCH v2 12/16] iommufd: Implement ioctl to mark HWPT for preservation Samiullah Khawaja
2026-04-27 17:56 ` [PATCH v2 13/16] iommufd: Persist iommu hardware pagetables for live update Samiullah Khawaja
2026-04-27 17:56 ` [PATCH v2 14/16] iommufd: Add APIs to preserve/unpreserve a vfio cdev Samiullah Khawaja
2026-04-27 17:56 ` [PATCH v2 15/16] vfio/pci: Preserve the iommufd state of the " Samiullah Khawaja
2026-04-27 17:56 ` [PATCH v2 16/16] iommufd/selftest: Add test to verify iommufd preservation 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=afUe71D8JfgmA0BG@google.com \
--to=dmatlack@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=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=skhawaja@google.com \
--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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.