All of lore.kernel.org
 help / color / mirror / Atom feed
From: Baolu Lu <baolu.lu@linux.intel.com>
To: Samiullah Khawaja <skhawaja@google.com>
Cc: baolu.lu@linux.intel.com, Joerg Roedel <joro@8bytes.org>,
	Will Deacon <will@kernel.org>, Jason Gunthorpe <jgg@ziepe.ca>,
	David Woodhouse <dwmw2@infradead.org>,
	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>,
	Ankit Soni <Ankit.Soni@amd.com>,
	Nicolin Chen <nicolinc@nvidia.com>, John Starks <dev@jstarks.net>
Subject: Re: [PATCH v6 05/18] iommu: Implement device and IOMMU HW preservation
Date: Sat, 31 Oct 2026 13:27:05 +0800	[thread overview]
Message-ID: <7b059c0e-3b60-4d8c-b7d2-7dcb89a51c6f@linux.intel.com> (raw)
In-Reply-To: <auVfqaDhk25JUkYd@google.com>

On 10/31/2026 11:39 AM, Samiullah Khawaja wrote:
> On Sat, Oct 31, 2026 at 11:04:22AM +0800, Baolu Lu wrote:
>> On 10/31/2026 9:45 AM, Samiullah Khawaja wrote:
>>>>> +
>>>>>  #if IS_ENABLED(CONFIG_IOMMUFD_TEST)
>>>>>  void iommu_device_unregister_bus(struct iommu_device *iommu,
>>>>>                   const struct bus_type *bus,
>>>>> @@ -626,8 +668,8 @@ DEFINE_MUTEX(iommu_probe_device_lock);
>>>>>  static int __iommu_probe_device(struct device *dev, struct 
>>>>> list_head *group_list)
>>>>>  {
>>>>> +    struct group_device *gdev, *gdev2;
>>>>>      struct iommu_group *group;
>>>>> -    struct group_device *gdev;
>>>>>      int ret;
>>>>>      /*
>>>>> @@ -661,6 +703,13 @@ static int __iommu_probe_device(struct device 
>>>>> *dev, struct list_head *group_list
>>>>>          goto err_put_group;
>>>>>      }
>>>>> +    for_each_group_device(group, gdev2) {
>>>>> +        if (dev_iommu_has_preserved_state(gdev2->dev)) {
>>>>> +            ret = -EBUSY;
>>>>> +            goto err_free_gdev;
>>>>> +        }
>>>>> +    }
>>>>> +
>>>>>      /*
>>>>>       * The gdev must be in the list before calling
>>>>>       * iommu_setup_default_domain()
>>>>> @@ -697,6 +746,7 @@ static int __iommu_probe_device(struct device 
>>>>> *dev, struct list_head *group_list
>>>>>  err_remove_gdev:
>>>>>      list_del(&gdev->list);
>>>>> +err_free_gdev:
>>>>>      __iommu_group_free_device(group, gdev);
>>>>>  err_put_group:
>>>>>      iommu_deinit_device(dev);
>>>>> @@ -3543,6 +3593,26 @@ bool iommu_group_dma_owner_claimed(struct 
>>>>> iommu_group *group)
>>>>>  }
>>>>>  EXPORT_SYMBOL_GPL(iommu_group_dma_owner_claimed);
>>>>> +/**
>>>>> + * iommu_group_is_singleton() - Query if group contains exactly 
>>>>> one device
>>>>> + * @group: The group.
>>>>> + *
>>>>> + * Return: true if group contains exactly 1 device, false otherwise.
>>>>> + */
>>>>
>>>> We discussed this interface before, and the consensus was that such an
>>>> interface is not feasible, because the membership of an iommu_group is
>>>> not fixed, given the hot-plug support of buses like PCI.
>>>>
>>>> I am fine with the usage model of ensuring the iommu group of a
>>>> preserved device to be a singleton, but I don't think we even need such
>>>> a kAPI. It should be handled case by case.
>>>
>>> The iommu_group membership can change, this is why we check it in two
>>> places, both under group->mutex:
>>>
>>> - During preservation we check that the group is a singleton, and check
>>>   again after setting device_ser.
>>> - During probe we refuse to add a device to a group that has a preserved
>>>   device.
>>>
>>> So if a device is added to the group while we are preserving, either the
>>> probe fails because the group already has a preserved device, or the
>>> preservation fails because the group is no longer a singleton. Could you
>>> please elaborate what you mean by handling it case by case?
>>
>> I am fine with the singleton-group checking logic you described above,
>> but I don't think we need a helper like iommu_group_is_singleton(). It
>> drops group->mutex before returning, so its result may already be stale
>> when the caller uses it. That makes it easy to misuse in the future.
>>
>> I'd prefer to open-code the check where group->mutex is already held, as
>> iommu_attach_device() does today:
> 
> struct iommu_group is private to drivers/iommu/iommu.c, and
> iommu_preserve_device() is in liveupdate.c, so open coding it there is
> tricky.
> 
> You are correct that it drops the lock before returning. That is why I
> recheck the singleton state after setting device_ser, which handles the
> race.
> 
> I was thinking of adding something like iommu_group_lock() and
> iommu_group_unlock() for this, but the number of devices check also
> needs struct iommu_group definition.
> 
> To avoid misuse, I can add a comment on iommu_group_is_singleton() that
> the result may be stale and the caller must recheck. What do you think?

I would suggest something like this:

size_t iommu_group_device_count(struct iommu_group *group)
{
         size_t count;

         mutex_lock(&group->mutex);
         count = list_count_nodes(&group->devices);
         mutex_unlock(&group->mutex);

         return count;
}

and, add a comment stating that the device count may change after the
function returns, so the caller must recheck it.

Thanks,
baolu

  reply	other threads:[~2026-10-31  5:27 UTC|newest]

Thread overview: 54+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-10-25  2:19 [PATCH v6 00/18] iommu: Add live update state preservation Samiullah Khawaja
2026-10-25  2:19 ` [PATCH v6 01/18] iommu: Implement IOMMU Live update FLB callbacks Samiullah Khawaja
2026-10-25  2:19 ` [PATCH v6 02/18] iommu/pages: Add APIs to preserve/unpreserve/restore iommu pages Samiullah Khawaja
2026-10-30  1:26   ` Baolu Lu
2026-10-30 19:41     ` Samiullah Khawaja
2026-10-25  2:19 ` [PATCH v6 03/18] iommupt: Implement preserve/unpreserve/restore callbacks Samiullah Khawaja
2026-10-30  3:07   ` Baolu Lu
2026-10-30 19:42     ` Samiullah Khawaja
2026-10-25  2:19 ` [PATCH v6 04/18] iommu: Implement IOMMU domain preservation Samiullah Khawaja
2026-10-30  4:24   ` Baolu Lu
2026-10-25  2:19 ` [PATCH v6 05/18] iommu: Implement device and IOMMU HW preservation Samiullah Khawaja
2026-10-30  5:12   ` Baolu Lu
2026-10-31  1:45     ` Samiullah Khawaja
2026-10-31  3:04       ` Baolu Lu
2026-10-31  3:39         ` Samiullah Khawaja
2026-10-31  5:27           ` Baolu Lu [this message]
2026-10-31  5:34       ` Baolu Lu
2026-10-25  2:19 ` [PATCH v6 06/18] iommu/vt-d: Implement device and iommu preserve/unpreserve ops Samiullah Khawaja
2026-10-28  1:51   ` Baolu Lu
2026-10-28  3:10     ` Samiullah Khawaja
2026-10-25  2:19 ` [PATCH v6 07/18] iommu/vt-d: Clear unpreserved context entries during shutdown Samiullah Khawaja
2026-10-28  3:18   ` Baolu Lu
2026-10-29  0:34     ` Samiullah Khawaja
2026-10-29  3:18   ` Baolu Lu
2026-10-29 22:00     ` Samiullah Khawaja
2026-10-25  2:19 ` [PATCH v6 08/18] iommu: Add APIs to get iommu and device preserved state Samiullah Khawaja
2026-10-30  6:03   ` Baolu Lu
2026-10-31  1:55     ` Samiullah Khawaja
2026-10-25  2:19 ` [PATCH v6 09/18] iommu/vt-d: Combine disable_dmar_iommu() and free_dmar_iommu() Samiullah Khawaja
2026-10-28  6:01   ` Baolu Lu
2026-10-29  0:33     ` Samiullah Khawaja
2026-10-25  2:19 ` [PATCH v6 10/18] iommu/vt-d: Restore IOMMU state and reclaimed domain ids Samiullah Khawaja
2026-10-28  7:14   ` Baolu Lu
2026-10-29  0:32     ` Samiullah Khawaja
2026-10-25  2:19 ` [PATCH v6 11/18] iommu/vt-d: Preserve PASID table of preserved device Samiullah Khawaja
2026-10-29  7:42   ` Baolu Lu
2026-10-25  2:19 ` [PATCH v6 12/18] iommu: Restore and reattach preserved domains to devices Samiullah Khawaja
2026-10-25  2:19 ` [PATCH v6 13/18] iommu/vt-d: Handle reattach of the restored domain Samiullah Khawaja
2026-10-29  8:28   ` Baolu Lu
2026-10-29 22:34     ` Samiullah Khawaja
2026-10-29 23:38       ` Baolu Lu
2026-10-30 19:39         ` Samiullah Khawaja
2026-10-25  2:19 ` [PATCH v6 14/18] iommufd: Implement ioctl to mark HWPT for preservation Samiullah Khawaja
2026-10-30  7:20   ` Baolu Lu
2026-10-31  1:48     ` Samiullah Khawaja
2026-10-25  2:19 ` [PATCH v6 15/18] iommufd: Persist iommu hardware pagetables for live update Samiullah Khawaja
2026-10-31  2:46   ` Baolu Lu
2026-10-31  3:24     ` Samiullah Khawaja
2026-10-25  2:19 ` [PATCH v6 16/18] iommufd: Add APIs to preserve/unpreserve a vfio cdev Samiullah Khawaja
2026-10-31  3:31   ` Baolu Lu
2026-10-31  3:57     ` Samiullah Khawaja
2026-10-25  2:19 ` [PATCH v6 17/18] vfio/pci: Preserve the iommufd state of the " Samiullah Khawaja
2026-10-31  5:56   ` Baolu Lu
2026-10-25  2:19 ` [PATCH v6 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=7b059c0e-3b60-4d8c-b7d2-7dcb89a51c6f@linux.intel.com \
    --to=baolu.lu@linux.intel.com \
    --cc=Ankit.Soni@amd.com \
    --cc=akpm@linux-foundation.org \
    --cc=alex@shazbot.org \
    --cc=dev@jstarks.net \
    --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=nicolinc@nvidia.com \
    --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 \
    /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.