On Fri, Jul 26, 2019 at 09:56:51AM +0800, Lu Baolu wrote:
> I think current code doesn't do the right thing. The user asks the iommu
> driver to use identity domain for a device, but the driver force it back
> to DMA domain because of the device address capability.
>
>> expensive. I don't think
This adds Kconfig option INTEL_IOMMU_SCALABLE_MODE_DEFAULT_ON
to make it easier for distributions to enable or disable the
Intel IOMMU scalable mode by default during kernel build.
Signed-off-by: Lu Baolu
---
drivers/iommu/Kconfig | 12
drivers/iommu/intel-iommu.c | 7
Hi,
On 11/11/19 10:05 PM, Qian Cai wrote:
On Nov 11, 2019, at 12:23 AM, Lu Baolu wrote:
The scalable mode is defined in VT-d 3.0. The scalable mode capability
could be checked by reading /sys/devices/virtual/iommu/dmar*/intel-
iommu/ecap. It's currently not friendly for reading. You need
Although we don't generally expect IRQs to fire for a suspended IOMMU,
there are certain situations (particularly with debug options) where
we might legitimately end up with the pm_runtime_get_if_in_use() call
from rk_iommu_irq() returning 0. Since this doesn't represent an actual
error, follow
On Fri, 8 Nov 2019 16:25:08 +0100
Jean-Philippe Brucker wrote:
> Enable PASID for PCI devices that support it. Since the SSID tables are
> allocated by arm_smmu_attach_dev(), PASID has to be enabled early enough.
> arm_smmu_dev_feature_enable() would be too late, since by that time the
> main
On Fri, 8 Nov 2019 16:25:07 +0100
Jean-Philippe Brucker wrote:
> Let add_device() clean up after itself. The iommu_bus_init() function
> does call remove_device() on error, but other sites (e.g. of_iommu) do
> not.
>
> Don't free level-2 stream tables because we'd have to track if we
>
On Fri, 8 Nov 2019 16:25:06 +0100
Jean-Philippe Brucker wrote:
> The SMMU can support up to 20 bits of SSID. Add a second level of page
> tables to accommodate this. Devices that support more than 1024 SSIDs now
> have a table of 1024 L1 entries (8kB), pointing to tables of 1024 context
>
Hi Adrian,
On Mon, Nov 04, 2019 at 01:58:52PM +0800, Adrian Huang wrote:
> 2) When set_device_exclusion_range() parses the IVMD of devce id
> '4200', the exclusion range of the amd_iommu struct becomes:
>
> iommu->exclusion_start = 0x9F58D000;
>
On Fri, 8 Nov 2019 16:25:05 +0100
Jean-Philippe Brucker wrote:
> At the moment, the SMMUv3 driver implements only one stage-1 or stage-2
> page directory per device. However SMMUv3 allows more than one address
> space for some devices, by providing multiple stage-1 page directories. In
>
On Sat, Nov 02, 2019 at 10:53:11AM +0800, Lu Baolu wrote:
> Update the INTEL IOMMU (VT-d) entry and add myself as the
> co-maintainer. I have several years of VT-d development
> experience and have actively contributed to Intel VT-d
> driver during recent two years. I volunteer to take this
>
On Fri, Nov 08, 2019 at 04:58:03PM +0100, Eric Auger wrote:
> For both PASID-based-Device-TLB Invalidate Descriptor and
> Device-TLB Invalidate Descriptor, the Physical Function Source-ID
> value is split according to this layout:
>
> PFSID[3:0] is set at offset 12 and PFSID[15:4] is put at
On Sun, Nov 10, 2019 at 09:27:44AM -0800, Deepa Dinamani wrote:
> The intel-iommu driver assumes that the iommu state is
> cleaned up at the start of the new kernel.
> But, when we try to kexec boot something other than the
> Linux kernel, the cleanup cannot be relied upon.
> Hence, cleanup before
On Thu, Oct 17, 2019 at 04:39:19AM -0700, Yian Chen wrote:
> VT-d RMRR (Reserved Memory Region Reporting) regions are reserved
> for device use only and should not be part of allocable memory pool of OS.
>
> BIOS e820_table reports complete memory map to OS, including OS usable
> memory ranges
On Mon, Nov 11, 2019 at 12:17:20PM +0100, Jean-Philippe Brucker wrote:
> Since commit 7723f4c5ecdb ("driver core: platform: Add an error message
> to platform_get_irq*()"), platform_get_irq_byname() displays an error
> when the IRQ isn't found. Since the SMMUv3 driver uses that function to
> query
On 11/11/2019 11:17, Jean-Philippe Brucker wrote:
Since commit 7723f4c5ecdb ("driver core: platform: Add an error message
to platform_get_irq*()"), platform_get_irq() displays an error when the
IRQ isn't found. Remove the error print from the SMMU driver. Note the
slight change of behaviour: no
On Fri, 8 Nov 2019 16:25:04 +0100
Jean-Philippe Brucker wrote:
> When a master supports substream ID, allocate a table with multiple
> context descriptors for its stage-1 domain. For the moment S1CDMax is
> still 0 in the STE, so the additional context descriptors are ignored.
>
> Context
On Mon, Nov 11, 2019 at 12:17:20PM +0100, Jean-Philippe Brucker wrote:
> Since commit 7723f4c5ecdb ("driver core: platform: Add an error message
> to platform_get_irq*()"), platform_get_irq_byname() displays an error
> when the IRQ isn't found. Since the SMMUv3 driver uses that function to
> query
On Thu, Nov 07, 2019 at 02:30:20PM +, Will Deacon wrote:
> The following changes since commit 1be08f458d1602275b02f5357ef069957058f3fd:
>
> iommu/io-pgtable-arm: Support all Mali configurations (2019-10-01 12:16:47
> +0100)
>
> are available in the Git repository at:
>
>
Hi John,
On Mon, Nov 11, 2019 at 11:52:38AM +, John Garry wrote:
> On 11/11/2019 11:17, Jean-Philippe Brucker wrote:
> > Since commit 7723f4c5ecdb ("driver core: platform: Add an error message
> > to platform_get_irq*()"), platform_get_irq_byname() displays an error
> > when the IRQ isn't
On Wed, Nov 06, 2019 at 11:35:44AM +0900, Yoshihiro Shimoda wrote:
> Yoshihiro Shimoda (6):
> iommu/ipmmu-vmsa: Remove all unused register definitions
> iommu/ipmmu-vmsa: tidyup register definitions
> iommu/ipmmu-vmsa: Add helper functions for MMU "context" registers
> iommu/ipmmu-vmsa:
> On Nov 11, 2019, at 12:23 AM, Lu Baolu wrote:
>
> The scalable mode is defined in VT-d 3.0. The scalable mode capability
> could be checked by reading /sys/devices/virtual/iommu/dmar*/intel-
> iommu/ecap. It's currently not friendly for reading. You need to decode
> it according to the
On Mon, Nov 04, 2019 at 03:01:01PM +0800, Yong Wu wrote:
> Yong Wu (7):
> iommu/mediatek: Correct the flush_iotlb_all callback
> iommu/mediatek: Add a new tlb_lock for tlb_flush
> iommu/mediatek: Use gather to achieve the tlb range flush
> iommu/mediatek: Delete the leaf in the tlb_flush
>
On 11 November 2019 at 09:16 am, Christian Zigotzky wrote:
On 11 November 2019 at 09:12 am, Christian Zigotzky wrote:
On 10 November 2019 at 08:27 am, Christian Zigotzky wrote:
On 07 November 2019 at 10:53 am, Christian Zigotzky wrote:
On 05 November 2019 at 05:28 pm, Christoph Hellwig wrote:
On 11/11/2019 11:17, Jean-Philippe Brucker wrote:
Since commit 7723f4c5ecdb ("driver core: platform: Add an error message
to platform_get_irq*()"), platform_get_irq_byname() displays an error
when the IRQ isn't found. Since the SMMUv3 driver uses that function to
query which interrupt method is
On Tue, 5 Nov 2019 16:34:48 +0800
zhangfei wrote:
> Hi, Jonathan
>
> On 2019/11/1 上午1:53, Jonathan Cameron wrote:
> > On Tue, 29 Oct 2019 14:40:16 +0800
> > Zhangfei Gao wrote:
> >
> >> Register qm to uacce framework for user crypto driver
> >>
> >> Signed-off-by: Zhangfei Gao
> >>
Since commit 7723f4c5ecdb ("driver core: platform: Add an error message
to platform_get_irq*()"), platform_get_irq() displays an error when the
IRQ isn't found. Remove the error print from the SMMU driver. Note the
slight change of behaviour: no message is printed if platform_get_irq()
returns
On Tue, 5 Nov 2019 15:43:31 +0800
zhangfei wrote:
> Hi, Jonathan
>
> Thanks for the suggestions
>
> On 2019/11/1 上午1:13, Jonathan Cameron wrote:
> > On Tue, 29 Oct 2019 14:40:15 +0800
> > Zhangfei Gao wrote:
> >
> >> From: Kenneth Lee
> >>
> >> Uacce (Unified/User-space-access-intended
Since commit 7723f4c5ecdb ("driver core: platform: Add an error message
to platform_get_irq*()"), platform_get_irq_byname() displays an error
when the IRQ isn't found. Since the SMMUv3 driver uses that function to
query which interrupt method is available, the message is now displayed
during boot
On 11 November 2019 at 09:12 am, Christian Zigotzky wrote:
On 10 November 2019 at 08:27 am, Christian Zigotzky wrote:
On 07 November 2019 at 10:53 am, Christian Zigotzky wrote:
On 05 November 2019 at 05:28 pm, Christoph Hellwig wrote:
On Tue, Nov 05, 2019 at 08:56:27AM +0100, Christian
On 10 November 2019 at 08:27 am, Christian Zigotzky wrote:
On 07 November 2019 at 10:53 am, Christian Zigotzky wrote:
On 05 November 2019 at 05:28 pm, Christoph Hellwig wrote:
On Tue, Nov 05, 2019 at 08:56:27AM +0100, Christian Zigotzky wrote:
Hi All,
We still have DMA problems with some PCI
30 matches
Mail list logo
