From: Nicolin Chen <nicolinc@nvidia.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>, 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>, Pratyush Yadav <pratyush@kernel.org>,
Pasha Tatashin <pasha.tatashin@soleen.com>,
David Matlack <dmatlack@google.com>,
"Andrew Morton" <akpm@linux-foundation.org>,
Pranjal Shrivastava <praan@google.com>,
Vipin Sharma <vipinsh@google.com>
Subject: Re: [PATCH v5 15/18] iommufd: Persist iommu hardware pagetables for live update
Date: Wed, 7 Oct 2026 14:31:47 -0700 [thread overview]
Message-ID: <asa6Q4t1pqn9gz3P@nvidia.com> (raw)
In-Reply-To: <20260921004834.2601285-16-skhawaja@google.com>
On Mon, Sep 21, 2026 at 12:48:31AM +0000, Samiullah Khawaja wrote:
> diff --git a/drivers/iommu/iommufd/iommufd_private.h b/drivers/iommu/iommufd/iommufd_private.h
> index a33b32708afa..a4ddc29ec5ae 100644
> --- a/drivers/iommu/iommufd/iommufd_private.h
> +++ b/drivers/iommu/iommufd/iommufd_private.h
> @@ -98,6 +98,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
> + u32 nr_preserved_domains;
> +#endif
In iommufd, "num_" is used more often than "nr_".
> unsigned long iova_alignment;
> };
>
> @@ -398,6 +401,7 @@ struct iommufd_hwpt_paging {
> bool enforce_cache_coherency : 1;
> bool nest_parent : 1;
> #ifdef CONFIG_IOMMU_LIVEUPDATE
> + bool liveupdate_preserved;
> u64 liveupdate_token;
> #endif
> /* Head at iommufd_ioas::hwpt_list */
> +static inline bool iopt_liveupdate_immutable(const struct io_pagetable *iopt)
> +{
> + return iopt->nr_preserved_domains > 0;
> +}
It's used in io_pagetable file only. I'd move it out of the header:
static inline bool iopt_liveupdate_immutable(const struct io_pagetable *iopt)
{
bool immutable = false;
lockdep_assert_held(&iopt->domains_rwsem);
#ifdef CONFIG_IOMMU_LIVEUPDATE
/* iopt becomes immutable once liveupdate preservation starts */
immutable = iopt->num_preserved_domains;
#endif
return immutable;
}
> diff --git a/drivers/iommu/iommufd/liveupdate.c b/drivers/iommu/iommufd/liveupdate.c
> +static bool ioas_set_immutable(struct iommufd_ioas *ioas, bool set)
> +{
> + bool was_immutable;
> +
> + down_write(&ioas->iopt.domains_rwsem);
> + was_immutable = ioas->iopt.nr_preserved_domains > 0;
> + if (set)
> + ioas->iopt.nr_preserved_domains++;
> + else if (!WARN_ON(!was_immutable))
> + ioas->iopt.nr_preserved_domains--;
> +
> + up_write(&ioas->iopt.domains_rwsem);
> +
> + return was_immutable;
> +}
Since it has to handle refcount, an unset doesn't really unset the
flag, which is confusing.
Maybe just:
iopt_inc_num_preserved_domains
iopt_dec_num_preserved_domains
> +static int check_iopt_pages_preserved(struct liveupdate_session *s,
> + struct iommufd_hwpt_paging *hwpt)
static int iopt_validate_preserved_memory(struct io_pagetable *iopt,
struct liveupdate_session *s)
> +{
> + u32 req_seals = F_SEAL_SEAL | F_SEAL_GROW | F_SEAL_SHRINK;
> + struct iopt_area *area;
> + int ret = 0;
> +
> + down_read(&hwpt->ioas->iopt.iova_rwsem);
> + 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;
Move req_seals inside the for loop.
> +static int iommufd_liveupdate_preserve(struct liveupdate_file_op_args *args)
[...]
> + iommufd_ser = mem;
> + iommufd_ser->nr_hwpts = nr_hwpts;
> +
> + /* Preserve HWPTs */
> + i = 0;
> + xa_lock(&ictx->objects);
> + xa_for_each_marked(&ictx->objects, index, obj, IOMMUFD_OBJ_LIVEUPDATE_MARK) {
[...]
> + }
> + xa_unlock(&ictx->objects);
> +
> + /* Store the actual number of HWPTs that are preserved */
> + iommufd_ser->nr_hwpts = i;
iommufd_ser->nr_hwpts is set twice. First one seems redundant.
> +++ b/include/linux/kho/abi/iommufd.h
> +/**
> + * struct iommu_hwpt_ser - IOMMUFD HWPT serialized state
> + * @domain_data: Physical address of the serialized state of associated domain
Then, it could be domain_ser_phys?
> + * @token: User provided token
> + * @reclaimed: Whether the HWPT is reclaimed
Once the hwpt is reclaimed, could we clear domain_data to indicate
"it is reclaimed" instead of a separate field?
Nicolin
next prev parent reply other threads:[~2026-10-07 21:32 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-21 0:48 [PATCH v5 00/18] iommu: Add live update state preservation Samiullah Khawaja
2026-09-21 0:48 ` [PATCH v5 01/18] memfd: export memfd_get_seals() Samiullah Khawaja
2026-09-21 0:48 ` [PATCH v5 02/18] iommu: Implement IOMMU Live update FLB callbacks Samiullah Khawaja
2026-10-06 23:31 ` Nicolin Chen
2026-09-21 0:48 ` [PATCH v5 03/18] iommu/pages: Add APIs to preserve/unpreserve/restore iommu pages Samiullah Khawaja
2026-09-21 0:48 ` [PATCH v5 04/18] iommupt: Implement preserve/unpreserve/restore callbacks Samiullah Khawaja
2026-09-21 0:48 ` [PATCH v5 05/18] iommu: Implement IOMMU domain preservation Samiullah Khawaja
2026-09-21 0:48 ` [PATCH v5 06/18] iommu: Implement device and IOMMU HW preservation Samiullah Khawaja
2026-10-07 3:21 ` Nicolin Chen
2026-09-21 0:48 ` [PATCH v5 07/18] iommu/vt-d: Implement device and iommu preserve/unpreserve ops Samiullah Khawaja
2026-10-08 7:54 ` Baolu Lu
2026-09-21 0:48 ` [PATCH v5 08/18] iommu/vt-d: Clear unpreserved context entries during shutdown Samiullah Khawaja
2026-09-21 0:48 ` [PATCH v5 09/18] iommu: Add APIs to get iommu and device preserved state Samiullah Khawaja
2026-09-21 0:48 ` [PATCH v5 10/18] iommu/vt-d: Restore IOMMU state and reclaimed domain ids Samiullah Khawaja
2026-09-21 0:48 ` [PATCH v5 11/18] iommu: Restore and reattach preserved domains to devices Samiullah Khawaja
2026-10-07 19:44 ` Nicolin Chen
2026-09-21 0:48 ` [PATCH v5 12/18] iommu/vt-d: Handle reattach of the restored domain Samiullah Khawaja
2026-09-21 0:48 ` [PATCH v5 13/18] iommu/vt-d: Preserve PASID table of preserved device Samiullah Khawaja
2026-09-21 0:48 ` [PATCH v5 14/18] iommufd: Implement ioctl to mark HWPT for preservation Samiullah Khawaja
2026-10-07 20:17 ` Nicolin Chen
2026-09-21 0:48 ` [PATCH v5 15/18] iommufd: Persist iommu hardware pagetables for live update Samiullah Khawaja
2026-09-23 23:59 ` John Starks
2026-09-24 17:49 ` Samiullah Khawaja
2026-10-07 21:31 ` Nicolin Chen [this message]
2026-09-21 0:48 ` [PATCH v5 16/18] iommufd: Add APIs to preserve/unpreserve a vfio cdev Samiullah Khawaja
2026-10-07 22:00 ` Nicolin Chen
2026-09-21 0:48 ` [PATCH v5 17/18] vfio/pci: Preserve the iommufd state of the " Samiullah Khawaja
2026-09-21 0:48 ` [PATCH v5 18/18] 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=asa6Q4t1pqn9gz3P@nvidia.com \
--to=nicolinc@nvidia.com \
--cc=akpm@linux-foundation.org \
--cc=alex@shazbot.org \
--cc=baolu.lu@linux.intel.com \
--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=linux-kernel@vger.kernel.org \
--cc=pasha.tatashin@soleen.com \
--cc=praan@google.com \
--cc=pratyush@kernel.org \
--cc=robin.murphy@arm.com \
--cc=shuah@kernel.org \
--cc=skhawaja@google.com \
--cc=vipinsh@google.com \
--cc=will@kernel.org \
--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.