mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Samiullah Khawaja <skhawaja@google.com>
To: Ankit Soni <Ankit.Soni@amd.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, 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 v4 11/18] iommu: Restore and reattach preserved domains to devices
Date: Fri, 14 Aug 2026 19:46:01 +0000	[thread overview]
Message-ID: <an9mwcflLcLtwDrn@google.com> (raw)
In-Reply-To: <xssagtjtc27kxprwyz7exeiotigcr3ksnvr53ap56ialuqlfe4@xql3pr5va6m5>

On Fri, Aug 14, 2026 at 04:59:50PM +0000, Ankit Soni wrote:
>On Sat, Aug 08, 2026 at 02:27:16AM +0000, Samiullah Khawaja wrote:
>> During default domain setup, restore the preserved domains by restoring
>> the page tables using restore() iommupt op. Associated the restored
>> domain with the iommu group of the preserved device, and reattach the
>> domain to the device.
>>
>> Signed-off-by: Samiullah Khawaja <skhawaja@google.com>
>> ---
>>  drivers/iommu/iommu.c            |  76 ++++++++++++++++++
>>  drivers/iommu/liveupdate.c       | 130 +++++++++++++++++++++++++++++++
>>  include/linux/iommu-liveupdate.h |  69 ++++++++++++++++
>>  3 files changed, 275 insertions(+)
>>
>
>../..
>
>> diff --git a/drivers/iommu/liveupdate.c b/drivers/iommu/liveupdate.c
>> index 20acf123b47a..04c0212cd81b 100644
>> --- a/drivers/iommu/liveupdate.c
>> +++ b/drivers/iommu/liveupdate.c
>> @@ -708,3 +708,133 @@ void iommu_unpreserve_device(struct iommu_domain *domain, struct device *dev)
>>  	liveupdate_flb_put_outgoing(&iommu_flb);
>>  }
>>  EXPORT_SYMBOL_GPL(iommu_unpreserve_device);
>> +
>> +static inline bool match_device_ser(struct iommu_device_ser *match,
>> +				    struct pci_dev *pdev)
>> +{
>> +	return match->devid == pci_dev_id(pdev) && match->pci_domain_nr == pci_domain_nr(pdev->bus);
>> +}
>> +
>> +/**
>> + * iommu_init_device_preserved_data() - Initialize preserved state for device
>> + * @dev: Target device
>> + *
>> + * Looks up incoming Live Update state for @dev and attaches it to the device if
>> + * found.
>> + */
>> +void iommu_init_device_preserved_data(struct device *dev)
>> +{
>> +	struct iommu_device_ser *device_ser = NULL;
>> +	struct iommu_device_array_ser *array;
>> +	struct iommu_flb_obj *flb_obj;
>> +	int ret, idx;
>> +
>> +	if (!dev_is_pci(dev))
>> +		return;
>> +
>> +	ret = iommu_liveupdate_flb_get_incoming(&flb_obj);
>> +	if (ret)
>> +		return;
>> +
>> +	mutex_lock(&flb_obj->lock);
>> +	array = phys_to_virt(flb_obj->ser->device_array_phys);
>> +	iommu_liveupdate_for_each_arr(array) {
>> +		iommu_liveupdate_for_each_obj(array, device_ser, idx) {
>> +			if (match_device_ser(device_ser, to_pci_dev(dev))) {
>> +				device_ser->hdr.flags |= IOMMU_SER_FLAG_INCOMING;
>> +				goto out;
>> +			}
>> +		}
>> +	}
>> +
>> +	device_ser = NULL;
>> +out:
>> +	WRITE_ONCE(dev->iommu->device_ser, device_ser);
>> +	mutex_unlock(&flb_obj->lock);
>> +	liveupdate_flb_put_incoming(&iommu_flb);
>> +}
>> +EXPORT_SYMBOL(iommu_init_device_preserved_data);
>> +
>> +/**
>> + * iommu_release_restored_device() - Release a restored device
>> + * @dev: Target device
>> + */
>> +void iommu_release_restored_device(struct device *dev)
>> +{
>> +	/*
>> +	 * We do not support releasing the restored devices that are not
>> +	 * reclaimed by the device drivers as they can fallback to the default
>> +	 * domain.
>> +	 */
>> +	BUG_ON(dev_iommu_restored_state(dev));
>
>Hi,

Hi,

Thanks for looking at this.

>After a successful live update this is one sysfs write away, and nothing in
>the series disarms it.
>
>At PCI probe, iommu_init_device_preserved_data() matches the incoming FLB on
>devid + pci_domain_nr and sets IOMMU_SER_FLAG_INCOMING.
>Nothing clears the flag or device_ser afterwards. The group is meanwhile owned
>on behalf of iommufd (iommu.c:3229-3231, "will be reclaimed later by the
>entity (iommufd) that preserved them"), and iommufd_liveupdate_retrieve() is
>-EOPNOTSUPP, so the reclaim that would end the restored state cannot happen
>yet. The device is left with the state permanently set.

Yes, these points are valid and this is intentional. The IOMMU
persistence support is split into two phases as mentioned in the cover
letter. The reclaim logic in iommufd will come later as a phase 2. The
preserved devices go to normal state when these are reclaimed through
iommufd.

https://lore.kernel.org/all/20260128195943.GY1641016@ziepe.ca/

Regarding the handling of sysfs, my concern is about it coming back and
going to default domain as mentioned in the comment. But I will evaluate
if we can allow device tear down here and reattach it to the preserved
domain.

Also please see the patchset breakdown here:
https://docs.google.com/document/d/1enDn-uPE9U77U-xHEnzn6HHGKiePSAtMIP8EDU3NO0M

Btw since this phase 1 is relatively stable and I don't expect many
changes in it. I have started reviving the Phase 2 patches and will be
sending them out as RFC soon if you want to experiment with it.

Sami


  reply	other threads:[~2026-08-14 19:46 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-08-08  2:27 [PATCH v4 00/18] iommu: Add live update state preservation Samiullah Khawaja
2026-08-08  2:27 ` [PATCH v4 01/18] memfd: export memfd_get_seals() Samiullah Khawaja
2026-08-08  2:27 ` [PATCH v4 02/18] iommu: Implement IOMMU Live update FLB callbacks Samiullah Khawaja
2026-08-08  2:27 ` [PATCH v4 03/18] iommu/pages: Add APIs to preserve/unpreserve/restore iommu pages Samiullah Khawaja
2026-08-08  2:27 ` [PATCH v4 04/18] iommupt: Implement preserve/unpreserve/restore callbacks Samiullah Khawaja
2026-08-08  2:27 ` [PATCH v4 05/18] iommu: Implement IOMMU domain preservation Samiullah Khawaja
2026-08-08  2:27 ` [PATCH v4 06/18] iommu: Implement device and IOMMU HW preservation Samiullah Khawaja
2026-08-08  2:27 ` [PATCH v4 07/18] iommu/vt-d: Implement device and iommu preserve/unpreserve ops Samiullah Khawaja
2026-08-08  2:27 ` [PATCH v4 08/18] iommu/vt-d: Clear unpreserved context entries during shutdown Samiullah Khawaja
2026-08-08  2:27 ` [PATCH v4 09/18] iommu: Add APIs to get iommu and device preserved state Samiullah Khawaja
2026-08-12  6:29   ` Ankit Soni
2026-08-12 23:23     ` Samiullah Khawaja
2026-08-08  2:27 ` [PATCH v4 10/18] iommu/vt-d: Restore IOMMU state and reclaimed domain ids Samiullah Khawaja
2026-08-08  2:27 ` [PATCH v4 11/18] iommu: Restore and reattach preserved domains to devices Samiullah Khawaja
2026-08-14 16:59   ` Ankit Soni
2026-08-14 19:46     ` Samiullah Khawaja [this message]
2026-08-08  2:27 ` [PATCH v4 12/18] iommu/vt-d: Handle reattach of the restored domain Samiullah Khawaja
2026-08-08  2:27 ` [PATCH v4 13/18] iommu/vt-d: Preserve PASID table of preserved device Samiullah Khawaja
2026-08-08  2:27 ` [PATCH v4 14/18] iommufd: Implement ioctl to mark HWPT for preservation Samiullah Khawaja
2026-08-08  2:27 ` [PATCH v4 15/18] iommufd: Persist iommu hardware pagetables for live update Samiullah Khawaja
2026-08-08  2:27 ` [PATCH v4 16/18] iommufd: Add APIs to preserve/unpreserve a vfio cdev Samiullah Khawaja
2026-08-08  2:27 ` [PATCH v4 17/18] vfio/pci: Preserve the iommufd state of the " Samiullah Khawaja
2026-08-08  2:27 ` [PATCH v4 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=an9mwcflLcLtwDrn@google.com \
    --to=skhawaja@google.com \
    --cc=Ankit.Soni@amd.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=vipinsh@google.com \
    --cc=will@kernel.org \
    /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

all inboxes | Powered by JetHome®