> From: Lu Baolu
> Sent: Wednesday, July 6, 2022 10:55 AM
>
> The disable_dmar_iommu() is called when IOMMU initialization fails or
> the IOMMU is hot-removed from the system. In both cases, there is no
> need to clear the IOMMU translation data structures for devices.
>
> On the initialization
> From: Baolu Lu
> Sent: Sunday, July 3, 2022 12:34 PM
>
> On 2022/7/1 15:58, Tian, Kevin wrote:
> >> From: Lu Baolu Sent: Wednesday, June 29,
> >> 2022 3:47 PM
> >>
> >> The disable_dmar_iommu() is called when IOMMU initialization fails
> >
> From: Lu Baolu
> Sent: Saturday, July 2, 2022 9:56 AM
>
> The Intel IOMMU hot-add process starts from dmar_device_hotplug(). It
> uses the global dmar_global_lock to synchronize all the hot-add and
> hot-remove paths. In the hot-add path, the new IOMMU data structures
> are allocated firstly
> From: Lu Baolu
> Sent: Saturday, July 2, 2022 9:56 AM
>
> -out_unlock:
> + set_bit(num, iommu->domain_ids);
> + info->refcnt= 1;
> + info->did = num;
> + info->iommu = iommu;
> + domain->nid = iommu->node;
One nit. this line should be removed as it's
> From: Lu Baolu
> Sent: Saturday, July 2, 2022 9:56 AM
>
> Switch dmar unit sequence id allocation and release from bitmap to IDA
> interface.
>
> Signed-off-by: Lu Baolu
Reviewed-by: Kevin Tian
___
iommu mailing list
> From: Lu Baolu
> Sent: Wednesday, June 29, 2022 3:47 PM
>
> Using a global device_domain_lock spinlock to protect per-domain device
> tracking lists is an inefficient way, especially considering this lock
> is also needed in the hot paths. This optimizes the locking mechanism
> by converting
> From: Lu Baolu
> Sent: Wednesday, June 29, 2022 3:47 PM
>
> + spin_lock_irqsave(_domain_lock, flags);
> list_for_each_entry(info, >devices, link) {
> - if (!info->dev)
> - continue;
> -
suppose you can replace all spin_lock_irqsave() with spin_lock()
> From: Lu Baolu
> Sent: Wednesday, June 29, 2022 3:47 PM
>
> Fold __dmar_remove_one_dev_info() into dmar_remove_one_dev_info()
> which
> is its only caller. Make the spin lock critical range only cover the
> device list change code and remove some unnecessary checks.
>
> Signed-off-by: Lu
> From: Lu Baolu
> Sent: Wednesday, June 29, 2022 3:47 PM
>
> The iommu->lock is used to protect the per-IOMMU domain ID resource.
> Moving the lock into the ID alloc/free helpers makes the code more
> compact. At the same time, the device_domain_lock is irrelevant to
> the domain ID resource,
> From: Lu Baolu
> Sent: Wednesday, June 29, 2022 3:47 PM
>
> The disable_dmar_iommu() is called when IOMMU initialization fails or
> the IOMMU is hot-removed from the system. In both cases, there is no
> need to clear the IOMMU translation data structures for devices.
>
> On the initialization
> From: Lu Baolu
> Sent: Wednesday, June 29, 2022 3:47 PM
>
> The domain_translation_struct debugfs node is used to dump the DMAR
> page
> tables for the PCI devices. It potentially races with setting domains to
> devices. The existing code uses the global spinlock device_domain_lock to
> avoid
> From: Lu Baolu
> Sent: Wednesday, June 29, 2022 3:47 PM
>
> v3:
> - Split reduction of lock ranges from changing irqsave.
>https://lore.kernel.org/linux-
> iommu/BN9PR11MB52760A3D7C6BF1AF9C9D34658CAA9@BN9PR11MB5276.
> namprd11.prod.outlook.com/
> - Fully initialize the dev_info before
> From: Baolu Lu
> Sent: Friday, July 1, 2022 11:13 AM
>
> On 6/30/22 4:29 PM, Tian, Kevin wrote:
> >> From: Lu Baolu
> >> Sent: Saturday, June 25, 2022 8:52 PM
> >>
> >> In the IOMMU hot-add path, there's a need to check whether an IOMMU
>
> From: Alexey Kardashevskiy
> Sent: Friday, July 1, 2022 12:58 PM
>
> On 4/8/22 01:23, Jason Gunthorpe via iommu wrote:
> > IOMMU_CACHE means that normal DMAs do not require any additional
> coherency
> > mechanism and is the basic uAPI that VFIO exposes to userspace. For
> > instance VFIO
> From: Robin Murphy
> Sent: Thursday, June 30, 2022 4:22 PM
>
> On 2022-06-29 20:47, Nicolin Chen wrote:
> > On Fri, Jun 24, 2022 at 03:19:43PM -0300, Jason Gunthorpe wrote:
> >> On Fri, Jun 24, 2022 at 06:35:49PM +0800, Yong Wu wrote:
> >>
> > It's not used in VFIO context. "return 0" just
> From: Lu Baolu
> Sent: Saturday, June 25, 2022 8:52 PM
>
> If the available hardware exceeds DMAR_UNITS_SUPPORTED (previously set
> to MAX_IO_APICS, or 128), it causes these messages: "DMAR: Failed to
> allocate seq_id", "DMAR: Parse DMAR table failure.", and "x2apic: IRQ
> remapping doesn't
> From: Lu Baolu
> Sent: Saturday, June 25, 2022 8:52 PM
>
> The g_iommus is not used anywhere. Remove it to avoid dead code.
>
> Signed-off-by: Lu Baolu
Reviewed-by: Kevin Tian
___
iommu mailing list
iommu@lists.linux-foundation.org
> From: Lu Baolu
> Sent: Saturday, June 25, 2022 8:52 PM
>
> In the IOMMU hot-add path, there's a need to check whether an IOMMU
> has been probed. Instead of checking the IOMMU pointer in the global
> list, it's better to allocate a flag bit in iommu->flags for this
> purpose.
Sorry I didn't
> From: Lu Baolu
> Sent: Saturday, June 25, 2022 8:52 PM
>
> +struct iommu_domain_info {
> + struct intel_iommu *iommu;
> + unsigned int refcnt;
> + u16 did;
> +};
> +
> struct dmar_domain {
> int nid;/* node id */
> -
> - unsigned int
> From: Lu Baolu
> Sent: Saturday, June 25, 2022 8:52 PM
>
> @@ -1062,11 +1040,14 @@ static int alloc_iommu(struct dmar_drhd_unit
> *drhd)
> if (!iommu)
> return -ENOMEM;
>
> - if (dmar_alloc_seq_id(iommu) < 0) {
> + iommu->seq_id = ida_alloc_range(_seq_ids, 0,
> +
> From: Lu Baolu
> Sent: Saturday, June 25, 2022 8:52 PM
>
> It is not used anywhere. Remove it to avoid dead code.
>
> Signed-off-by: Lu Baolu
Reviewed-by: Kevin Tian
___
iommu mailing list
iommu@lists.linux-foundation.org
> From: Baolu Lu
> Sent: Tuesday, June 28, 2022 7:34 PM
>
> On 2022/6/28 16:50, Tian, Kevin wrote:
> >> From: Baolu Lu
> >> Sent: Tuesday, June 28, 2022 1:41 PM
> >>>>struct iommu_domain {
> >>>> unsig
> From: Jean-Philippe Brucker
> Sent: Tuesday, June 28, 2022 5:44 PM
>
> On Tue, Jun 28, 2022 at 08:39:36AM +, Tian, Kevin wrote:
> > > From: Lu Baolu
> > > Sent: Tuesday, June 21, 2022 10:44 PM
> > >
> > > Tweak the I/O page f
> From: Baolu Lu
> Sent: Tuesday, June 28, 2022 1:54 PM
> >> +u32 iommu_sva_get_pasid(struct iommu_sva *handle)
> >> +{
> >> + struct iommu_domain *domain =
> >> + container_of(handle, struct iommu_domain, bond);
> >> +
> >> + return domain->mm->pasid;
> >> +}
> >>
> From: Baolu Lu
> Sent: Tuesday, June 28, 2022 1:41 PM
> >
> >> struct iommu_domain {
> >>unsigned type;
> >>const struct iommu_domain_ops *ops;
> >>unsigned long pgsize_bitmap;/* Bitmap of page sizes in use */
> >> - iommu_fault_handler_t handler;
> >> - void *handler_token;
> From: Lu Baolu
> Sent: Tuesday, June 21, 2022 10:44 PM
>
> Rename iommu-sva-lib.c[h] to iommu-sva.c[h] as it contains all code
> for SVA implementation in iommu core.
>
> Signed-off-by: Lu Baolu
> Reviewed-by: Jean-Philippe Brucker
Reviewed-by: Kevin Tian
> From: Lu Baolu
> Sent: Tuesday, June 21, 2022 10:44 PM
>
> Tweak the I/O page fault handling framework to route the page faults to
> the domain and call the page fault handler retrieved from the domain.
> This makes the I/O page fault handling framework possible to serve more
> usage scenarios
> From: Lu Baolu
> Sent: Tuesday, June 21, 2022 10:44 PM
> +/*
> + * I/O page fault handler for SVA
> + */
> +enum iommu_page_response_code
> +iommu_sva_handle_iopf(struct iommu_fault *fault, void *data)
> +{
> + vm_fault_t ret;
> + struct mm_struct *mm;
> + struct vm_area_struct
> From: Lu Baolu
> Sent: Tuesday, June 21, 2022 10:44 PM
> +struct iommu_sva *iommu_sva_bind_device(struct device *dev, struct
> mm_struct *mm)
> +{
> + struct iommu_domain *domain;
> + ioasid_t max_pasids;
> + int ret = -EINVAL;
> +
> + /* Allocate mm->pasid if necessary. */
> From: Lu Baolu
> Sent: Tuesday, June 21, 2022 10:44 PM
>
> Add support for SVA domain allocation and provide an SVA-specific
> iommu_domain_ops.
>
> Signed-off-by: Lu Baolu
Reviewed-by: Kevin Tian
___
iommu mailing list
> From: Lu Baolu
> Sent: Tuesday, June 21, 2022 10:44 PM
>
> The sva iommu_domain represents a hardware pagetable that the IOMMU
> hardware could use for SVA translation. This adds some infrastructure
> to support SVA domain in the iommu common layer. It includes:
>
> - Extend the iommu_domain
> From: Lu Baolu
> Sent: Tuesday, June 21, 2022 10:44 PM
>
> Use this field to save the number of PASIDs that a device is able to
> consume. It is a generic attribute of a device and lifting it into the
> per-device dev_iommu struct could help to avoid the boilerplate code
> in various IOMMU
> From: Lu Baolu
> Sent: Tuesday, June 21, 2022 10:44 PM
>
> Use this field to keep the number of supported PASIDs that an IOMMU
> hardware is able to support. This is a generic attribute of an IOMMU
> and lifting it into the per-IOMMU device structure makes it possible
> to allocate a PASID for
> From: Robin Murphy
> Sent: Saturday, June 25, 2022 2:00 AM
>
> Use the new interface to check the capabilities for our device
> specifically.
>
> Reviewed-by: Lu Baolu
> Signed-off-by: Robin Murphy
Reviewed-by: Kevin Tian
___
iommu mailing list
> From: Robin Murphy
> Sent: Saturday, June 25, 2022 1:52 AM
>
> Since IOMMU groups are mandatory for drivers to support, it stands to
> reason that any device which has been successfully added to a group
> must be on a bus supported by that IOMMU driver, and therefore a domain
> viable for any
> From: Nicolin Chen
> Sent: Friday, June 24, 2022 4:00 AM
>
> Un-inline the domain specific logic from the attach/detach_group ops into
> two paired functions vfio_iommu_alloc_attach_domain() and
> vfio_iommu_detach_destroy_domain() that strictly deal with creating and
> destroying struct
> From: Lu Baolu
> Sent: Thursday, June 23, 2022 2:57 PM
>
> The IOMMU driver shares the pasid table for PCI alias devices. When the
> RID2PASID entry of the shared pasid table has been filled by the first
> device, the subsequent device will encounter the "DMAR: Setup RID2PASID
> failed"
> From: Yong Wu
> Sent: Friday, June 24, 2022 1:39 PM
>
> On Thu, 2022-06-23 at 19:44 -0700, Nicolin Chen wrote:
> > On Fri, Jun 24, 2022 at 09:35:49AM +0800, Baolu Lu wrote:
> > > External email: Use caution opening links or attachments
> > >
> > >
> > > On 2022/6/24 04:00, Nicolin Chen wrote:
>
> From: Alex Williamson
> Sent: Thursday, June 23, 2022 6:17 AM
>
> >
> > ret = -EIO;
> > - domain->domain = iommu_domain_alloc(bus);
> > + domain->domain = iommu_domain_alloc(iommu_api_dev->dev-
> >bus);
>
> It makes sense to move away from a bus centric interface to iommu ops
> and I
> From: Robin Murphy
> Sent: Wednesday, June 22, 2022 3:55 PM
>
> On 2022-06-16 23:23, Nicolin Chen wrote:
> > On Thu, Jun 16, 2022 at 06:40:14AM +, Tian, Kevin wrote:
> >
> >>> The domain->ops validation was added, as a precaution, for mixed-
> dri
> From: Lu Baolu
> Sent: Wednesday, June 22, 2022 12:41 PM
>
> The IOMMU driver shares the pasid table for PCI alias devices. When the
> RID2PASID entry of the shared pasid table has been filled by the first
> device, the subsequent devices will encounter the "DMAR: Setup RID2PASID
> failed"
> From: Baolu Lu
> Sent: Wednesday, June 22, 2022 11:28 AM
>
> On 2022/6/22 11:06, Tian, Kevin wrote:
> >> From: Baolu Lu
> >> Sent: Tuesday, June 21, 2022 5:04 PM
> >>
> >> On 2022/6/21 13:48, Tian, Kevin wrote:
> >>>&
> From: Baolu Lu
> Sent: Tuesday, June 21, 2022 5:04 PM
>
> On 2022/6/21 13:48, Tian, Kevin wrote:
> >> From: Baolu Lu
> >> Sent: Tuesday, June 21, 2022 12:28 PM
> >>
> >> On 2022/6/21 11:46, Tian, Kevin wrote:
> >>>&g
> From: Baolu Lu
> Sent: Tuesday, June 21, 2022 12:28 PM
>
> On 2022/6/21 11:46, Tian, Kevin wrote:
> >> From: Baolu Lu
> >> Sent: Tuesday, June 21, 2022 11:39 AM
> >>
> >> On 2022/6/21 10:54, Tian, Kevin wrote:
> >>>> From: Lu Baol
> From: Baolu Lu
> Sent: Tuesday, June 21, 2022 11:39 AM
>
> On 2022/6/21 10:54, Tian, Kevin wrote:
> >> From: Lu Baolu
> >> Sent: Monday, June 20, 2022 4:17 PM
> >> @@ -2564,7 +2564,7 @@ static int domain_add_dev_info(struct
>
> From: Lu Baolu
> Sent: Monday, June 20, 2022 4:17 PM
> @@ -2564,7 +2564,7 @@ static int domain_add_dev_info(struct
> dmar_domain *domain, struct device *dev)
> ret = intel_pasid_setup_second_level(iommu,
> domain,
> dev,
> From: Lu Baolu
> Sent: Tuesday, June 7, 2022 9:50 AM
>
> +
> +static const struct iommu_domain_ops intel_svm_domain_ops = {
> + .set_dev_pasid = intel_svm_attach_dev_pasid,
> + .block_dev_pasid= intel_svm_detach_dev_pasid,
> + .free =
> From: Baolu Lu
> Sent: Friday, June 10, 2022 3:16 PM
> >
> >> +#define __IOMMU_DOMAIN_HOST_VA(1U << 5) /* Host CPU virtual
> address */
> >
> > Do you mean general CPU VA? or Host CPU VA, I'm reading the latter as
> 2nd
> > stage?
>
> Host CPU VA. In the near future, we will add another
> From: Nicolin Chen
> Sent: Friday, June 17, 2022 6:41 AM
>
> > ...
> > > - if (resv_msi) {
> > > + if (resv_msi && !domain->msi_cookie) {
> > > ret = iommu_get_msi_cookie(domain->domain,
> > > resv_msi_base);
> > > if (ret && ret != -ENODEV)
> > >
> From: Nicolin Chen
> Sent: Thursday, June 16, 2022 8:03 AM
>
> Un-inline the domain specific logic from the attach/detach_group ops into
> two paired functions vfio_iommu_alloc_attach_domain() and
> vfio_iommu_detach_destroy_domain() that strictly deal with creating and
> destroying struct
> From: Nicolin Chen
> Sent: Thursday, June 16, 2022 8:03 AM
>
> All devices in emulated_iommu_groups have pinned_page_dirty_scope
> set, so the update_dirty_scope in the first list_for_each_entry
> is always false. Clean it up, and move the "if update_dirty_scope"
> part from the
> From: Nicolin Chen
> Sent: Thursday, June 16, 2022 8:03 AM
>
> The domain->ops validation was added, as a precaution, for mixed-driver
> systems. However, at this moment only one iommu driver is possible. So
> remove it.
It's true on a physical platform. But I'm not sure whether a virtual
> From: Nicolin Chen
> Sent: Thursday, June 16, 2022 8:03 AM
>
> From: Jason Gunthorpe
>
> The KVM mechanism for controlling wbinvd is based on OR of the coherency
> property of all devices attached to a guest, no matter those devices are
> attached to a single domain or multiple domains.
>
>
> From: Nicolin Chen
> Sent: Thursday, June 16, 2022 8:03 AM
>
> Cases like VFIO wish to attach a device to an existing domain that was
> not allocated specifically from the device. This raises a condition
> where the IOMMU driver can fail the domain attach because the domain and
> device are
> From: Baolu Lu
> Sent: Wednesday, June 15, 2022 9:10 PM
>
> On 2022/6/15 14:22, Tian, Kevin wrote:
> >> From: Baolu Lu
> >> Sent: Tuesday, June 14, 2022 3:21 PM
> >>
> >> On 2022/6/14 14:49, Tian, Kevin wrote:
> >>>&
> From: Nicolin Chen
> Sent: Wednesday, June 15, 2022 4:45 AM
>
> Hi Kevin,
>
> On Wed, Jun 08, 2022 at 11:48:27PM +, Tian, Kevin wrote:
> > > > > The KVM mechanism for controlling wbinvd is only triggered during
> > > > > kvm_vfio_grou
> From: Baolu Lu
> Sent: Tuesday, June 14, 2022 3:21 PM
>
> On 2022/6/14 14:49, Tian, Kevin wrote:
> >> From: Lu Baolu
> >> Sent: Tuesday, June 14, 2022 10:51 AM
> >>
> >> The disable_dmar_iommu() is called when IOMMU initialization fails or
> &
> From: Baolu Lu
> Sent: Wednesday, June 15, 2022 9:54 AM
>
> On 2022/6/14 14:43, Tian, Kevin wrote:
> >> From: Lu Baolu
> >> Sent: Tuesday, June 14, 2022 10:51 AM
> >>
> >> The domain_translation_struct debugfs node is used to dump th
> From: Baolu Lu
> Sent: Tuesday, June 14, 2022 2:13 PM
>
> On 2022/6/14 13:36, Tian, Kevin wrote:
> >> From: Baolu Lu
> >> Sent: Tuesday, June 14, 2022 12:48 PM
> >>
> >> On 2022/6/14 12:02, Tian, Kevin wrote:
> >>>&
> From: Lu Baolu
> Sent: Tuesday, June 14, 2022 10:52 AM
>
> The device_domain_lock is used to protect the device tracking list of
> a domain. Remove unnecessary spin_lock/unlock()'s and move the necessary
> ones around the list access.
>
> Signed-off-by: Lu Baolu
> ---
>
> From: Lu Baolu
> Sent: Tuesday, June 14, 2022 10:52 AM
>
> Fold __dmar_remove_one_dev_info() into dmar_remove_one_dev_info()
> which
> is its only caller. Make the spin lock critical range only cover the
> device list change code and remove some unnecessary checks.
>
> Signed-off-by: Lu Baolu
> From: Lu Baolu
> Sent: Tuesday, June 14, 2022 10:52 AM
>
> When the IOMMU domain is about to be freed, it should not be set on any
> device. Instead of silently dealing with some bug cases, it's better to
> trigger a warning to report and fix any potential bugs at the first time.
>
>
> From: Lu Baolu
> Sent: Tuesday, June 14, 2022 10:52 AM
>
> The iommu->lock is used to protect changes in root/context/pasid tables
> and domain ID allocation. There's no use case to change these resources
> in any interrupt context. Hence there's no need to disable interrupts
> when helding
> From: Lu Baolu
> Sent: Tuesday, June 14, 2022 10:52 AM
>
> The iommu->lock is used to protect the per-IOMMU domain ID resource.
> Moving the lock into the ID alloc/free helpers makes the code more
> compact. At the same time, the device_domain_lock is irrelevant to
> the domain ID resource,
> From: Lu Baolu
> Sent: Tuesday, June 14, 2022 10:51 AM
>
> The disable_dmar_iommu() is called when IOMMU initialization fails or
> the IOMMU is hot-removed from the system. In both cases, there is no
> need to clear the IOMMU translation data structures for devices.
>
> On the initialization
> From: Lu Baolu
> Sent: Tuesday, June 14, 2022 10:51 AM
>
> The domain_translation_struct debugfs node is used to dump the DMAR
> page
> tables for the PCI devices. It potentially races with setting domains to
> devices. The existing code uses a global spinlock device_domain_lock to
> avoid the
> From: Baolu Lu
> Sent: Tuesday, June 14, 2022 12:48 PM
>
> On 2022/6/14 12:02, Tian, Kevin wrote:
> >> From: Lu Baolu
> >> Sent: Tuesday, June 14, 2022 11:44 AM
> >>
> >> This allows the upper layers to set a domain to a PASID of a device
>
> From: Lu Baolu
> Sent: Tuesday, June 14, 2022 11:44 AM
>
> This allows the upper layers to set a domain to a PASID of a device
> if the PASID feature is supported by the IOMMU hardware. The typical
> use cases are, for example, kernel DMA with PASID and hardware
> assisted mediated device
> From: Baolu Lu
> Sent: Friday, June 10, 2022 2:47 PM
>
> On 2022/6/10 03:01, Raj, Ashok wrote:
> > On Tue, Jun 07, 2022 at 09:49:33AM +0800, Lu Baolu wrote:
> >> @@ -218,6 +219,30 @@ static void dev_iommu_free(struct device *dev)
> >>kfree(param);
> >> }
> >>
> >> +static u32
> From: Jason Gunthorpe
> Sent: Friday, June 10, 2022 7:53 AM
>
> On Thu, Jun 09, 2022 at 05:25:42PM +, Raj, Ashok wrote:
> >
> > On Tue, Jun 07, 2022 at 09:49:32AM +0800, Lu Baolu wrote:
> > > Use this field to keep the number of supported PASIDs that an IOMMU
> > > hardware is able to
> From: Nicolin Chen
> Sent: Monday, June 6, 2022 2:19 PM
>
> All devices in emulated_iommu_groups have pinned_page_dirty_scope
> set, so the update_dirty_scope in the first list_for_each_entry
> is always false. Clean it up, and move the "if update_dirty_scope"
> part from the detach_group_done
> From: Nicolin Chen
> Sent: Monday, June 6, 2022 2:19 PM
>
> From: Jason Gunthorpe
>
> The KVM mechanism for controlling wbinvd is only triggered during
> kvm_vfio_group_add(), meaning it is a one-shot test done once the devices
> are setup.
It's not one-shot. kvm_vfio_update_coherency() is
> From: Nicolin Chen
> Sent: Monday, June 6, 2022 2:19 PM
>
> Cases like VFIO wish to attach a device to an existing domain that was
> not allocated specifically from the device. This raises a condition
> where the IOMMU driver can fail the domain attach because the domain and
> device are
> From: Jean-Philippe Brucker
> Sent: Wednesday, May 25, 2022 3:30 PM
>
> On Wed, May 25, 2022 at 02:04:49AM +, Tian, Kevin wrote:
> > > From: Jean-Philippe Brucker
> > > Sent: Tuesday, May 24, 2022 6:58 PM
> > >
> > > On Tue, May
> From: Baolu Lu
> Sent: Wednesday, June 1, 2022 7:02 PM
>
> On 2022/6/1 17:28, Tian, Kevin wrote:
> >> From: Lu Baolu
> >> Sent: Friday, May 27, 2022 2:30 PM
> >>
> >> When the IOMMU domain is about to be freed, it should not be set on
> any
> From: Baolu Lu
> Sent: Wednesday, June 1, 2022 5:37 PM
>
> On 2022/6/1 09:43, Tian, Kevin wrote:
> >> From: Jacob Pan
> >> Sent: Wednesday, June 1, 2022 1:30 AM
> >>>> In both cases the pasid is stored in the attach data instead of the
>
> From: Lu Baolu
> Sent: Friday, May 27, 2022 2:30 PM
>
> When the IOMMU domain is about to be freed, it should not be set on any
> device. Instead of silently dealing with some bug cases, it's better to
> trigger a warning to report and fix any potential bugs at the first time.
>
> static
> From: Lu Baolu
> Sent: Friday, May 27, 2022 2:30 PM
>
> The iommu->lock is used to protect the per-IOMMU pasid directory table
> and pasid table. Move the spinlock acquisition/release into the helpers
> to make the code self-contained.
>
> Signed-off-by: Lu Baolu
Reviewed-by: Kevin Tian ,
> From: Lu Baolu
> Sent: Friday, May 27, 2022 2:30 PM
>
> The iommu->lock is used to protect the per-IOMMU domain ID resource.
> Move the spinlock acquisition/release into the helpers where domain
> IDs are allocated and freed. The device_domain_lock is irrelevant to
> domain ID resources,
> From: Lu Baolu
> Sent: Friday, May 27, 2022 2:30 PM
>
> The IOMMU root table is allocated and freed in the IOMMU initialization
> code in static boot or hot-plug paths. There's no need for a spinlock.
s/hot-plug/hot-remove/
>
> Signed-off-by: Lu Baolu
Reviewed-by: Kevin Tian
> ---
>
> From: Lu Baolu
> Sent: Friday, May 27, 2022 2:30 PM
>
> Use pci_get_domain_bus_and_slot() instead of searching the global list
> to retrieve the pci device pointer. This removes device_domain_list
> global list as there are no consumers anymore.
>
> Signed-off-by: Lu Baolu
Reviewed-by:
> From: Lu Baolu
> Sent: Friday, May 27, 2022 2:30 PM
>
> The per-device device_domain_info data could be retrieved from the
> device itself. There's no need to search a global list.
>
> Signed-off-by: Lu Baolu
Reviewed-by: Kevin Tian
> ---
> drivers/iommu/intel/iommu.h | 2 --
>
> From: Jason Gunthorpe
> Sent: Wednesday, June 1, 2022 7:11 AM
>
> On Tue, May 31, 2022 at 10:22:32PM +0100, Robin Murphy wrote:
>
> > There are only 3 instances where we'll free a table while the domain is
> > live. The first is the one legitimate race condition, where two map requests
> >
> From: Jacob Pan
> Sent: Wednesday, June 1, 2022 4:44 AM
>
> Hi Jason,
>
> On Tue, 31 May 2022 16:05:50 -0300, Jason Gunthorpe
> wrote:
>
> > On Tue, May 31, 2022 at 10:29:55AM -0700, Jacob Pan wrote:
> >
> > > The reason why I store PASID at IOMMU domain is for IOTLB flush within
> > > the
> From: Jacob Pan
> Sent: Wednesday, June 1, 2022 1:30 AM
> > >
> > > In both cases the pasid is stored in the attach data instead of the
> > > domain.
> > >
> So during IOTLB flush for the domain, do we loop through the attach data?
Yes and it's required.
>
> > > DMA API pasid is no special
> From: Jason Gunthorpe
> Sent: Monday, May 30, 2022 8:23 PM
>
> On Tue, May 24, 2022 at 08:17:27AM -0700, Jacob Pan wrote:
> > Hi Jason,
> >
> > On Tue, 24 May 2022 10:50:34 -0300, Jason Gunthorpe
> wrote:
> >
> > > On Wed, May 18, 2022 at 11:21:15AM -0700, Jacob Pan wrote:
> > > > DMA
> From: Jason Gunthorpe
> Sent: Thursday, May 26, 2022 2:27 AM
>
> On Wed, May 25, 2022 at 02:26:37PM +0800, Baolu Lu wrote:
> > On 2022/5/25 09:31, Nobuhiro Iwamatsu wrote:
> > > +static const struct iommu_ops visconti_atu_ops = {
> > > + .domain_alloc = visconti_atu_domain_alloc,
> > > +
> From: Jean-Philippe Brucker
> Sent: Tuesday, May 24, 2022 6:58 PM
>
> On Tue, May 24, 2022 at 10:22:28AM +, Tian, Kevin wrote:
> > > From: Lu Baolu
> > > Sent: Thursday, May 19, 2022 3:21 PM
> > >
> > > The existing iommu SVA interfaces a
> From: Jason Gunthorpe
> Sent: Tuesday, May 24, 2022 9:39 PM
>
> On Tue, May 24, 2022 at 09:39:52AM +, Tian, Kevin wrote:
> > > From: Lu Baolu
> > > Sent: Thursday, May 19, 2022 3:21 PM
> > >
> > > The iommu_sva_domain represents a hardware
> From: Lu Baolu
> Sent: Thursday, May 19, 2022 3:21 PM
>
> These ops'es have been replaced with the dev_attach/detach_pasid domain
> ops'es. There's no need for them anymore. Remove them to avoid dead
> code.
>
> Signed-off-by: Lu Baolu
> Reviewed-by: Jean-Philippe Brucker
Reviewed-by:
> From: Lu Baolu
> Sent: Thursday, May 19, 2022 3:21 PM
>
> The existing iommu SVA interfaces are implemented by calling the SVA
> specific iommu ops provided by the IOMMU drivers. There's no need for
> any SVA specific ops in iommu_ops vector anymore as we can achieve
> this through the generic
> From: Baolu Lu
> Sent: Monday, May 23, 2022 3:13 PM
> > @@ -254,6 +259,7 @@ struct iommu_ops {
> > int (*def_domain_type)(struct device *dev);
> >
> > const struct iommu_domain_ops *default_domain_ops;
> > + const struct iommu_domain_ops *sva_domain_ops;
>
> Per Joerg's comment in
> From: Lu Baolu
> Sent: Thursday, May 19, 2022 3:21 PM
>
> The iommu_sva_domain represents a hardware pagetable that the IOMMU
> hardware could use for SVA translation. This adds some infrastructure
> to support SVA domain in the iommu common layer. It includes:
>
> - Add a new struct
> From: Lu Baolu
> Sent: Thursday, May 19, 2022 3:21 PM
>
> The current kernel DMA with PASID support is based on the SVA with a flag
> SVM_FLAG_SUPERVISOR_MODE. The IOMMU driver binds the kernel
> memory address
> space to a PASID of the device. The device driver programs the device with
>
> From: Lu Baolu
> Sent: Thursday, May 19, 2022 3:21 PM
>
> Use this field to keep the number of supported PASIDs that an IOMMU
> hardware is able to support. This is a generic attribute of an IOMMU
> and lifting it into the per-IOMMU device structure makes it possible
> to allocate a PASID for
> From: Tian, Kevin
> Sent: Monday, May 23, 2022 3:55 PM
>
> > From: Jacob Pan
> > +ioasid_t iommu_get_pasid_from_domain(struct device *dev, struct
> > iommu_domain *domain)
> > +{
> > + struct iommu_domain *tdomain;
> > + struct io
> From: Jacob Pan
> Sent: Thursday, May 19, 2022 2:21 AM
>
> DMA mapping API is the de facto standard for in-kernel DMA. It operates
> on a per device/RID basis which is not PASID-aware.
>
> Some modern devices such as Intel Data Streaming Accelerator, PASID is
> required for certain work
> From: Jacob Pan
> Sent: Thursday, May 19, 2022 2:21 AM
>
> IOMMU group maintains a PASID array which stores the associated IOMMU
> domains. This patch introduces a helper function to do domain to PASID
> look up. It will be used by TLB flush and device-PASID attach verification.
>
>
> From: Steve Wahl
> Sent: Thursday, May 19, 2022 3:58 AM
>
> On Fri, May 13, 2022 at 10:09:46AM +0800, Baolu Lu wrote:
> > On 2022/5/13 07:12, Steve Wahl wrote:
> > > On Thu, May 12, 2022 at 10:13:09AM -0500, Steve Wahl wrote:
> > > > To support up to 64 sockets with 10 DMAR units each (640),
> From: Jason Gunthorpe
> Sent: Friday, May 20, 2022 1:04 AM
>
> Since asserting dma ownership now causes the group to have its DMA
> blocked
> the iommu layer requires a working iommu. This means the dma_owner APIs
> cannot be used on the fake groups that VFIO creates. Test for this and
> avoid
1 - 100 of 775 matches
Mail list logo
