On Wed, Mar 18, 2020 at 3:48 PM Will Deacon wrote:
>
> On Tue, Jan 28, 2020 at 03:16:06PM -0700, Jordan Crouse wrote:
> > Support auxiliary domains for arm-smmu-v2 to initialize and support
> > multiple pagetables for a single SMMU context bank. Since the smmu-v2
> > hardware doesn't have any buil
On Tue, Jan 28, 2020 at 03:16:06PM -0700, Jordan Crouse wrote:
> Support auxiliary domains for arm-smmu-v2 to initialize and support
> multiple pagetables for a single SMMU context bank. Since the smmu-v2
> hardware doesn't have any built in support for switching the pagetable
> base it is left as
On Tue, Jan 28, 2020 at 03:00:16PM -0700, Jordan Crouse wrote:
> Add support to enable TTBR1 if the domain requests it via the
> DOMAIN_ATTR_SPLIT_TABLES attribute. If enabled by the hardware
> and pagetable configuration the driver will configure the TTBR1 region
> and program the domain pagetable
Hi Rob,
On Mon, Feb 24, 2020 at 04:31:29PM -0600, Rob Herring wrote:
> Arm SMMUv3.2 adds support for TLB range invalidate operations.
> Support for range invalidate is determined by the RIL bit in the IDR3
> register.
>
> The range invalidate is in units of the leaf page size and operates on
> 1-
On Wed, Mar 11, 2020 at 01:45:02PM +0100, Jean-Philippe Brucker wrote:
> The new pci_ats_supported() function checks if a device supports ATS and
> is allowed to use it.
>
> Signed-off-by: Jean-Philippe Brucker
> ---
> drivers/iommu/arm-smmu-v3.c | 18 +++---
> 1 file changed, 3 inse
On Wed, Mar 18, 2020 at 01:36:06PM -0500, Bjorn Helgaas wrote:
> On Mon, Feb 24, 2020 at 05:58:41PM +0100, Jean-Philippe Brucker wrote:
> > The Arm SMMUv3 driver uses pci_{enable,disable}_pasid() and related
> > functions. Export them to allow the driver to be built as a module.
> >
> > Signed-of
On Fri, Feb 28, 2020 at 06:25:37PM +0100, Jean-Philippe Brucker wrote:
> Hardware platforms usually describe the IOMMU topology using either
> device-tree pointers or vendor-specific ACPI tables. For virtual
> platforms that don't provide a device-tree, the virtio-iommu device
> contains a descrip
From: Hans de Goede
[ Upstream commit 81ee85d0462410de8c1b9761941fd6ed8c7b ]
Quoting from the comment describing the WARN functions in
include/asm-generic/bug.h:
* WARN(), WARN_ON(), WARN_ON_ONCE, and so on can be used to report
* significant kernel issues that need prompt attention if th
From: Hans de Goede
[ Upstream commit 81ee85d0462410de8c1b9761941fd6ed8c7b ]
Quoting from the comment describing the WARN functions in
include/asm-generic/bug.h:
* WARN(), WARN_ON(), WARN_ON_ONCE, and so on can be used to report
* significant kernel issues that need prompt attention if th
From: Zhenzhong Duan
[ Upstream commit b0bb0c22c4db623f2e7b1a471596fbf1c22c6dc5 ]
When base address in RHSA structure doesn't match base address in
each DRHD structure, the base address in last DRHD is printed out.
This doesn't make sense when there are multiple DRHD units, fix it
by printing t
From: Zhenzhong Duan
[ Upstream commit b0bb0c22c4db623f2e7b1a471596fbf1c22c6dc5 ]
When base address in RHSA structure doesn't match base address in
each DRHD structure, the base address in last DRHD is printed out.
This doesn't make sense when there are multiple DRHD units, fix it
by printing t
From: Zhenzhong Duan
[ Upstream commit b0bb0c22c4db623f2e7b1a471596fbf1c22c6dc5 ]
When base address in RHSA structure doesn't match base address in
each DRHD structure, the base address in last DRHD is printed out.
This doesn't make sense when there are multiple DRHD units, fix it
by printing t
From: Hans de Goede
[ Upstream commit 81ee85d0462410de8c1b9761941fd6ed8c7b ]
Quoting from the comment describing the WARN functions in
include/asm-generic/bug.h:
* WARN(), WARN_ON(), WARN_ON_ONCE, and so on can be used to report
* significant kernel issues that need prompt attention if th
From: Hans de Goede
[ Upstream commit 81ee85d0462410de8c1b9761941fd6ed8c7b ]
Quoting from the comment describing the WARN functions in
include/asm-generic/bug.h:
* WARN(), WARN_ON(), WARN_ON_ONCE, and so on can be used to report
* significant kernel issues that need prompt attention if th
From: Zhenzhong Duan
[ Upstream commit b0bb0c22c4db623f2e7b1a471596fbf1c22c6dc5 ]
When base address in RHSA structure doesn't match base address in
each DRHD structure, the base address in last DRHD is printed out.
This doesn't make sense when there are multiple DRHD units, fix it
by printing t
From: Megha Dey
[ Upstream commit ba3b01d7a6f4ab9f8a0557044c9a7678f64ae070 ]
Commit 6825d3ea6cde ("iommu/vt-d: Add debugfs support to show register
contents") dumps the register contents for all IOMMU devices.
Currently, a 64 bit read(dmar_readq) is done for all the IOMMU registers,
even though
From: Qian Cai
[ Upstream commit 2d48ea0efb8887ebba3e3720bb5b738aced4e574 ]
There are several places traverse RCU-list without holding any lock in
intel_iommu_init(). Fix them by acquiring dmar_global_lock.
WARNING: suspicious RCU usage
-
drivers/iommu/intel-iommu
From: Suravee Suthikulpanit
[ Upstream commit 730ad0ede130015a773229573559e97ba0943065 ]
Commit b9c6ff94e43a ("iommu/amd: Re-factor guest virtual APIC
(de-)activation code") accidentally left out the ir_data pointer when
calling modity_irte_ga(), which causes the function amd_iommu_update_ga()
t
From: Megha Dey
[ Upstream commit 1da8347d8505c137fb07ff06bbcd3f2bf37409bc ]
Currently, the intel iommu debugfs directory(/sys/kernel/debug/iommu/intel)
gets populated only when DMA remapping is enabled (dmar_disabled = 0)
irrespective of whether interrupt remapping is enabled or not.
Instead,
From: Daniel Drake
[ Upstream commit da72a379b2ec0bad3eb265787f7008bead0b040c ]
VMD subdevices are created with a PCI domain ID of 0x1 or
higher.
These subdevices are also handled like all other PCI devices by
dmar_pci_bus_notifier().
However, when dmar_alloc_pci_notify_info() take records
From: Hans de Goede
[ Upstream commit 81ee85d0462410de8c1b9761941fd6ed8c7b ]
Quoting from the comment describing the WARN functions in
include/asm-generic/bug.h:
* WARN(), WARN_ON(), WARN_ON_ONCE, and so on can be used to report
* significant kernel issues that need prompt attention if th
From: Zhenzhong Duan
[ Upstream commit b0bb0c22c4db623f2e7b1a471596fbf1c22c6dc5 ]
When base address in RHSA structure doesn't match base address in
each DRHD structure, the base address in last DRHD is printed out.
This doesn't make sense when there are multiple DRHD units, fix it
by printing t
From: Qian Cai
[ Upstream commit f5152416528c2295f35dd9c9bd4fb27c4032413d ]
Similar to the commit 02d715b4a818 ("iommu/vt-d: Fix RCU list debugging
warnings"), there are several other places that call
list_for_each_entry_rcu() outside of an RCU read side critical section
but with dmar_global_loc
Hi John,
On Thu, Jan 02, 2020 at 05:44:39PM +, John Garry wrote:
> And for the overall system, we have:
>
> PerfTop: 85864 irqs/sec kernel:89.6% exact: 0.0% lost: 0/34434 drop:
> 0/40116 [4000Hz cycles], (all, 96 CPUs)
>
Hi Krishna,
On Wed, Oct 30, 2019 at 05:07:11PM -0700, Krishna Reddy wrote:
> Changes in v4:
> Rebased on top of
> https://git.kernel.org/pub/scm/linux/kernel/git/will/linux.git/
> for-joerg/arm-smmu/updates.
> Updated arm-smmu-nvidia.c to use the tlb_sync implementation hook.
> Dropped patch tha
Just a gentle reminder, any comments?
Thanks,
Jacob
On Mon, 24 Feb 2020 15:26:37 -0800
Jacob Pan wrote:
> This patch is an initial step to replace Intel SVM code with the
> following IOMMU SVA ops:
> intel_svm_bind_mm() => iommu_sva_bind_device()
> intel_svm_unbind_mm() => iommu_sva_unbind_dev
On Mon, Feb 24, 2020 at 05:58:41PM +0100, Jean-Philippe Brucker wrote:
> The Arm SMMUv3 driver uses pci_{enable,disable}_pasid() and related
> functions. Export them to allow the driver to be built as a module.
>
> Signed-off-by: Jean-Philippe Brucker
Acked-by: Bjorn Helgaas
> ---
> drivers/
On Wed, Mar 18, 2020 at 05:13:59PM +, Robin Murphy wrote:
> On 2020-03-18 4:14 pm, Auger Eric wrote:
> > Hi,
> >
> > On 3/18/20 1:00 PM, Robin Murphy wrote:
> > > On 2020-03-18 11:40 am, Jean-Philippe Brucker wrote:
> > > > We don't currently support IOMMUs with a page granule larger than the
On 2020-03-18 4:14 pm, Auger Eric wrote:
Hi,
On 3/18/20 1:00 PM, Robin Murphy wrote:
On 2020-03-18 11:40 am, Jean-Philippe Brucker wrote:
We don't currently support IOMMUs with a page granule larger than the
system page size. The IOVA allocator has a BUG_ON() in this case, and
VFIO has a WARN_
On Wed, Mar 18, 2020 at 05:14:05PM +0100, Auger Eric wrote:
> Hi,
>
> On 3/18/20 1:00 PM, Robin Murphy wrote:
> > On 2020-03-18 11:40 am, Jean-Philippe Brucker wrote:
> >> We don't currently support IOMMUs with a page granule larger than the
> >> system page size. The IOVA allocator has a BUG_ON()
Hi,
On 3/18/20 1:00 PM, Robin Murphy wrote:
> On 2020-03-18 11:40 am, Jean-Philippe Brucker wrote:
>> We don't currently support IOMMUs with a page granule larger than the
>> system page size. The IOVA allocator has a BUG_ON() in this case, and
>> VFIO has a WARN_ON().
Adding Alex in CC in case h
On 2020-03-18 11:40 am, Jean-Philippe Brucker wrote:
We don't currently support IOMMUs with a page granule larger than the
system page size. The IOVA allocator has a BUG_ON() in this case, and
VFIO has a WARN_ON().
It might be possible to remove these obstacles if necessary. If the host
uses 64k
We don't currently support IOMMUs with a page granule larger than the
system page size. The IOVA allocator has a BUG_ON() in this case, and
VFIO has a WARN_ON().
It might be possible to remove these obstacles if necessary. If the host
uses 64kB pages and the guest uses 4kB, then a device driver ca
> On Mar 18, 2020, at 1:27 AM, Lu Baolu wrote:
>
> How about changing the commit subject to
> "iommu/vt-d: Silence RCU-list debugging warning in dmar_find_atsr()"?
Just a bit long which should be non-issue.
___
iommu mailing list
iommu@lists.linux-f
Hei hei,
gentle ping on this patch from two weeks ago. Did anyone have time to
look into it? Did I miss someone in Cc or sent it to the wrong lists
maybe?
On Mon, Mar 02, 2020 at 07:16:12PM +0100, Alexander Dahl wrote:
> For ARCH=x86 (32 bit) when you set CONFIG_IOMMU_INTEL since c5a5dc4cbbf4
> (
35 matches
Mail list logo
