Hi Saravana,
On Fri, Jul 1, 2022 at 1:11 AM Saravana Kannan wrote:
> On Mon, Jun 27, 2022 at 2:10 AM Tony Lindgren wrote:
> > * Saravana Kannan [220623 08:17]:
> > > On Thu, Jun 23, 2022 at 12:01 AM Tony Lindgren wrote:
> > > > * Saravana Kannan [220622 19:05]:
> > > > > On Tue, Jun 21, 2022
> 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
>
> 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
>
> + 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()
On 2022-07-01 08:19, Baolu Lu wrote:
On 2022/6/29 21:03, Robin Murphy wrote:
On 2019-06-12 01:28, Lu Baolu wrote:
The drhd and device scope list should be iterated with the
iommu global lock held. Otherwise, a suspicious RCU usage
message will be displayed.
[ 3.695886]
On Fri, Jul 1, 2022 at 1:10 AM Saravana Kannan wrote:
>
> On Thu, Jun 30, 2022 at 11:12 PM Tony Lindgren wrote:
> >
> > * Tony Lindgren [220701 08:33]:
> > > * Saravana Kannan [220630 23:25]:
> > > > On Thu, Jun 30, 2022 at 4:26 PM Rob Herring wrote:
> > > > >
> > > > > On Thu, Jun 30, 2022
On Fri, Jul 1, 2022 at 3:28 AM Saravana Kannan wrote:
>
> With commit 71066545b48e ("driver core: Set fw_devlink.strict=1 by
> default") the probing of TTY consoles could get delayed if they have
> optional suppliers that are listed in DT, but those suppliers don't
> probe by the time kernel boot
> 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
On 01/07/2022 00:41, Damien Le Moal wrote:
shost->dma_dev = dma_dev;
+ if (dma_dev->dma_mask) {
+ shost->max_sectors = min_t(unsigned int, shost->max_sectors,
+ dma_max_mapping_size(dma_dev) >> SECTOR_SHIFT);
+ }
Nit: you could remove
On 01/07/2022 00:49, Damien Le Moal wrote:
+ if (dma_dev) {
+ shost->max_sectors = min_t(unsigned int, shost->max_sectors,
+ dma_opt_mapping_size(dma_dev) >> SECTOR_SHIFT);
+ }
Hi Damien,
> Hmm... shost->max_sectors becomes the
On 2022/7/1 16:15, Tian, Kevin wrote:
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
On Fri, 2022-05-27 at 10:25 +0900, David Stevens wrote:
> On Tue, May 24, 2022 at 9:27 PM Niklas Schnelle
> wrote:
> > On Fri, 2021-08-06 at 19:34 +0900, David Stevens wrote:
> > > From: David Stevens
> > >
> > > This patch series adds support for per-domain dynamic pools of iommu
> > > bounce
On 01/07/2022 04:56, Feng Tang wrote:
inclination.
ok, what you are saying sounds reasonable. I just remember that when we
analyzed the longterm aging issue that we concluded that the FQ size and its
relation to the magazine size was a factor and this change makes me a little
worried about new
Hi Saravana,
On Fri, Jul 1, 2022 at 2:37 AM Saravana Kannan wrote:
> On Thu, Jun 23, 2022 at 5:08 AM Alexander Stein
> wrote:
> > Am Dienstag, 21. Juni 2022, 09:28:43 CEST schrieb Tony Lindgren:
> > > * Saravana Kannan [700101 02:00]:
> > > > Now that fw_devlink=on by default and fw_devlink
As iommu_device_sysfs_add() can fail, we should check the return value.
Signed-off-by: Bo Liu
---
drivers/iommu/amd/init.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/iommu/amd/init.c b/drivers/iommu/amd/init.c
index 3c82d9c5f1c0..a3c4fdd40f04 100644
---
> 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
On Thu, Jun 30, 2022 at 11:12 PM Tony Lindgren wrote:
>
> * Tony Lindgren [220701 08:33]:
> > * Saravana Kannan [220630 23:25]:
> > > On Thu, Jun 30, 2022 at 4:26 PM Rob Herring wrote:
> > > >
> > > > On Thu, Jun 30, 2022 at 5:11 PM Saravana Kannan
> > > > wrote:
> > > > >
> > > > > On Mon,
On 2022/7/1 15:53, Tian, Kevin wrote:
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
> 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
On 2022-06-30 21:36, Nicolin Chen wrote:
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 incompatible with each other.
> 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
> >> has been probed. Instead of checking the IOMMU
On 2022/7/1 04:36, Nicolin Chen wrote:
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 incompatible with each other.
> 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
On 2022/6/29 21:03, Robin Murphy wrote:
On 2019-06-12 01:28, Lu Baolu wrote:
The drhd and device scope list should be iterated with the
iommu global lock held. Otherwise, a suspicious RCU usage
message will be displayed.
[ 3.695886] =
[ 3.695917] WARNING:
Hi Saravana,
Am Freitag, 1. Juli 2022, 02:37:14 CEST schrieb Saravana Kannan:
> On Thu, Jun 23, 2022 at 5:08 AM Alexander Stein
>
> wrote:
> > Hi,
> >
> > Am Dienstag, 21. Juni 2022, 09:28:43 CEST schrieb Tony Lindgren:
> > > Hi,
> > >
> > > * Saravana Kannan [700101 02:00]:
> > > > Now that
On Thu, Jun 30, 2022 at 11:02 PM Alexander Stein
wrote:
>
> Hi Saravana,
>
> Am Freitag, 1. Juli 2022, 02:37:14 CEST schrieb Saravana Kannan:
> > On Thu, Jun 23, 2022 at 5:08 AM Alexander Stein
> >
> > wrote:
> > > Hi,
> > >
> > > Am Dienstag, 21. Juni 2022, 09:28:43 CEST schrieb Tony Lindgren:
On 2022-07-01 12:33, John Garry wrote:
On 01/07/2022 04:56, Feng Tang wrote:
inclination.
ok, what you are saying sounds reasonable. I just remember that when we
analyzed the longterm aging issue that we concluded that the FQ size
and its
relation to the magazine size was a factor and this
On Thu, Jun 30, 2022 at 09:39:59AM +0300, Xenia Ragiadakou wrote:
> The expression 1 << 31 results in undefined behaviour because the type of
> integer constant 1 is (signed) int and the result of shifting 1 by 31 bits
> is not representable in the (signed) int type.
>
> Change the type of 1 to
* Saravana Kannan [220701 08:21]:
> On Fri, Jul 1, 2022 at 1:10 AM Saravana Kannan wrote:
> >
> > On Thu, Jun 30, 2022 at 11:12 PM Tony Lindgren wrote:
> > >
> > > * Tony Lindgren [220701 08:33]:
> > > > * Saravana Kannan [220630 23:25]:
> > > > > On Thu, Jun 30, 2022 at 4:26 PM Rob Herring
Hi, Saravana,
On Fri, Jul 01, 2022 at 01:26:12AM -0700, Saravana Kannan wrote:
[...]
> Can you check if this hack helps? If so, then I can think about
> whether we can pick it up without breaking everything else. Copy-paste
> tab mess up warning.
Sorry for jumping in late and not even sure if
On Tue, Jun 14, 2022 at 10:30:21AM +0200, Jörg Rödel wrote:
> Hi all,
>
> after several problems with the current IOMMU mailing list (no DKIM
> support, poor b4 interoperability) we have decided to move the IOMMU
> development discussions to a new list hosted at lists.linux.dev.
>
> The new list
On Fri, Jul 01, 2022 at 11:21:48AM +0100, Robin Murphy wrote:
> > diff --git a/drivers/iommu/arm/arm-smmu/arm-smmu.c
> > b/drivers/iommu/arm/arm-smmu/arm-smmu.c
> > index 2ed3594f384e..072cac5ab5a4 100644
> > --- a/drivers/iommu/arm/arm-smmu/arm-smmu.c
> > +++
> -Original Message-
> From: Shameerali Kolothum Thodi
> Sent: 28 June 2022 09:00
> To: 'Robin Murphy' ; j...@8bytes.org;
> linux-arm-ker...@lists.infradead.org; linux-a...@vger.kernel.org;
> iommu@lists.linux-foundation.org
> Cc: j...@solid-run.com; Linuxarm ;
> h...@infradead.org;
On Fri, Jul 1, 2022 at 8:08 AM Sudeep Holla wrote:
>
> Hi, Saravana,
>
> On Fri, Jul 01, 2022 at 01:26:12AM -0700, Saravana Kannan wrote:
>
> [...]
>
> > Can you check if this hack helps? If so, then I can think about
> > whether we can pick it up without breaking everything else. Copy-paste
> >
A couple of functions directly reference the affinity mask. Route them
through irq_data_get_affinity_mask so they will pick up any refactoring
done there.
Signed-off-by: Samuel Holland
---
(no changes since v1)
include/linux/irq.h | 14 +++---
1 file changed, 7 insertions(+), 7
Some architectures and irqchip drivers modify the cpumask returned by
irq_data_get_affinity_mask, usually by copying in to it. This is
problematic for uniprocessor configurations, where the affinity mask
should be constant, as it is known at compile time.
Add and use a setter for the affinity
Now that the irq_data_update_affinity helper exists, enforce its use
by returning a a const cpumask from irq_data_get_affinity_mask.
Since the previous commit already updated places that needed to call
irq_data_update_affinity, this commit updates the remaining code that
either did not modify the
It does exactly the same thing as irq_data_update_effective_affinity.
Signed-off-by: Samuel Holland
---
Changes in v3:
- New patch to drop irq_init_effective_affinity
kernel/irq/manage.c | 10 +-
1 file changed, 1 insertion(+), 9 deletions(-)
diff --git a/kernel/irq/manage.c
This series solves some inconsistency with how IRQ affinity masks are
handled between SMP and non-SMP configurations.
In non-SMP configs, an IRQ's true affinity is always cpumask_of(0), so
irq_{,data_}get_affinity_mask now return that, instead of returning an
uninitialized per-IRQ cpumask. This
IRQ affinity masks are not allocated in uniprocessor configurations.
This requires special case non-SMP code in drivers for irqchips which
have per-CPU enable or mask registers.
Since IRQ affinity is always the same in a uniprocessor configuration,
we can provide a correct affinity mask without
The generic IPI code depends on the IRQ affinity mask being allocated
and initialized. This will not be the case if SMP is disabled. Fix up
the remaining driver that selected GENERIC_IRQ_IPI in a non-SMP config.
Reported-by: kernel test robot
Signed-off-by: Samuel Holland
---
(no changes since
An IRQ's effective affinity can only be different from its configured
affinity if there are multiple CPUs. Make it clear that this option is
only meaningful when SMP is enabled. Most of the relevant code in
irqdesc.c is already hidden behind CONFIG_SMP anyway.
Signed-off-by: Samuel Holland
---
The MIPS GIC irqchip driver may be selected in a uniprocessor
configuration, but it unconditionally registers an IPI domain.
Limit the part of the driver dealing with IPIs to only be compiled when
GENERIC_IRQ_IPI is enabled, which corresponds to an SMP configuration.
Reported-by: kernel test
On 01/07/2022 5:43 pm, Nicolin Chen wrote:
On Fri, Jul 01, 2022 at 11:21:48AM +0100, Robin Murphy wrote:
diff --git a/drivers/iommu/arm/arm-smmu/arm-smmu.c
b/drivers/iommu/arm/arm-smmu/arm-smmu.c
index 2ed3594f384e..072cac5ab5a4 100644
--- a/drivers/iommu/arm/arm-smmu/arm-smmu.c
+++
On 7/1/22 17:34, Will Deacon wrote:
On Thu, Jun 30, 2022 at 09:39:59AM +0300, Xenia Ragiadakou wrote:
The expression 1 << 31 results in undefined behaviour because the type of
integer constant 1 is (signed) int and the result of shifting 1 by 31 bits
is not representable in the (signed) int
On Fri, Jul 01, 2022 at 07:17:38PM +0100, Robin Murphy wrote:
> External email: Use caution opening links or attachments
>
>
> On 01/07/2022 5:43 pm, Nicolin Chen wrote:
> > On Fri, Jul 01, 2022 at 11:21:48AM +0100, Robin Murphy wrote:
> >
> > > > diff --git
This is a preparatory series for IOMMUFD v2 patches. It enforces error
code -EMEDIUMTYPE in iommu_attach_device() and iommu_attach_group() when
an IOMMU domain and a device/group are incompatible. It also drops the
useless domain->ops check since it won't fail in current environment.
These allow
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 whether those
devices are attached to a single domain or multiple domains.
On the other hand, the benefit to using separate domains was that
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 incompatible with each other.
This is a soft failure that can be resolved
The domain->ops validation was added, as a precaution, for mixed-driver
systems.
Per Robin's remarks,
* While bus_set_iommu() still exists, the core code prevents multiple
drivers from registering, so we can't really run into a situation of
having a mixed-driver system:
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 routine to the domain_list part.
Suggested-by: Jason Gunthorpe
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 vfio_domains.
Add the logic to check for EMEDIUMTYPE return code of
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 by dmar_parse_one_drhd() and then initialized by
dmar_hp_add_drhd().
The g_iommus and g_num_of_iommus is not used anywhere. Remove them to
avoid dead code.
Signed-off-by: Lu Baolu
Reviewed-by: Kevin Tian
---
drivers/iommu/intel/iommu.c | 44 -
1 file changed, 44 deletions(-)
diff --git a/drivers/iommu/intel/iommu.c
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 support X2APIC mode x2apic disabled"; and the system
fails to boot
It is not used anywhere. Remove it to avoid dead code.
Signed-off-by: Lu Baolu
Reviewed-by: Kevin Tian
---
drivers/iommu/intel/iommu.h | 1 -
drivers/iommu/intel/iommu.c | 18 --
2 files changed, 19 deletions(-)
diff --git a/drivers/iommu/intel/iommu.h
Switch dmar unit sequence id allocation and release from bitmap to IDA
interface.
Signed-off-by: Lu Baolu
---
drivers/iommu/intel/dmar.c | 35 ---
1 file changed, 8 insertions(+), 27 deletions(-)
diff --git a/drivers/iommu/intel/dmar.c
When a DMA domain is attached to a device, it needs to allocate a domain
ID from its IOMMU. Currently, the domain ID information is stored in two
static arrays embedded in the domain structure. This can lead to memory
waste when the driver is running on a small platform.
This optimizes these
Hi folks,
This is a follow-up series of changes proposed by this patch:
https://lore.kernel.org/linux-iommu/20220615183650.32075-1-steve.w...@hpe.com/
It removes several static arrays of size DMAR_UNITS_SUPPORTED and sets
the DMAR_UNITS_SUPPORTED to 1024.
This series is also available on
* Tony Lindgren [220701 08:33]:
> * Saravana Kannan [220630 23:25]:
> > On Thu, Jun 30, 2022 at 4:26 PM Rob Herring wrote:
> > >
> > > On Thu, Jun 30, 2022 at 5:11 PM Saravana Kannan
> > > wrote:
> > > >
> > > > On Mon, Jun 27, 2022 at 2:10 AM Tony Lindgren wrote:
> > > > >
> > > > > *
On 7/1/22 16:07, Tian, Kevin wrote:
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.
iommu_device_register returns an error code and, although it currently
never fails, we should check its return value anyway.
Signed-off-by: Bo Liu
---
drivers/iommu/virtio-iommu.c | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/drivers/iommu/virtio-iommu.c
63 matches
Mail list logo
