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: 22+ 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-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-04-27 17:56 ` [PATCH v2 07/16] iommu/vt-d: Implement device and iommu preserve/unpreserve ops 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-04-27 17:56 ` [PATCH v2 10/16] iommu: Restore and reattach preserved domains to devices Samiullah Khawaja
2026-04-27 17:56 ` [PATCH v2 11/16] iommu/vt-d: preserve PASID table of preserved device Samiullah Khawaja
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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox