public inbox for kvm@vger.kernel.org
 help / color / mirror / Atom feed
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.

  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