On Fri, 8 Jan 2021 15:52:13 +0100
Jean-Philippe Brucker wrote:
> The IOPF (I/O Page Fault) feature is now enabled independently from the
> SVA feature, because some IOPF implementations are device-specific and
> do not require IOMMU support for PCIe PRI or Arm SMMU stall.
>
> Enable IOPF
On Fri, 8 Jan 2021 15:52:14 +0100
Jean-Philippe Brucker wrote:
> Some systems allow devices to handle I/O Page Faults in the core mm. For
> example systems implementing the PCIe PRI extension or Arm SMMU stall
> model. Infrastructure for reporting these recoverable page faults was
> added to the
On 2021/1/19 19:16, Lianbo Jiang wrote:
This patchset is to fix the failure of deferred attach for iommu attach
device, it includes the following two patches:
[1] [PATCH 1/2] dma-iommu: use static-key to minimize the impact in the
fast-path
This is a prepared patch for the second one,
> +int iommu_do_deferred_attach(struct device *dev,
> + struct iommu_domain *domain)
I'd remove the "do_" from the name, it doesn't really add any value.
> +{
> + const struct iommu_ops *ops = domain->ops;
> +
> + if (unlikely(ops->is_attach_deferred &&
> +
On 2021-01-19 11:16, Lianbo Jiang wrote:
Currently, because domain attach allows to be deferred from iommu
driver to device driver, and when iommu initializes, the devices
on the bus will be scanned and the default groups will be allocated.
Due to the above changes, some devices could be added
On 2021-01-19 15:26, Christoph Hellwig wrote:
On Tue, Jan 19, 2021 at 07:16:15PM +0800, Lianbo Jiang wrote:
+static DEFINE_STATIC_KEY_FALSE(__deferred_attach);
Why the strange underscores? Wouldn't iommu_deferred_attach_enabled
be a better name?
- if
> On Jan 18, 2021, at 8:22 PM, Lu Baolu wrote:
>
> Do you mind posting the cap and ecap of the iommu used by your device?
>
> You can get it via sysfs, for example:
>
> /sys/bus/pci/devices/:00:14.0/iommu/intel-iommu# ls
> address cap domains_supported domains_used ecap version
On 2021-01-19 01:59, Zhen Lei wrote:
Some SMMUv3 implementation embed the Perf Monitor Group Registers (PMCG)
inside the first 64kB region of the SMMU. Since SMMU and PMCG are managed
by two separate drivers, and this driver depends on ARM_SMMU_V3, so the
SMMU driver reserves the corresponding
On Fri, 8 Jan 2021 15:52:15 +0100
Jean-Philippe Brucker wrote:
> When handling faults from the event or PRI queue, we need to find the
> struct device associated with a SID. Add a rb_tree to keep track of
> SIDs.
>
> Signed-off-by: Jean-Philippe Brucker
One totally trivial point if you happen
On Tue, Jan 19, 2021 at 07:16:15PM +0800, Lianbo Jiang wrote:
> +static DEFINE_STATIC_KEY_FALSE(__deferred_attach);
Why the strange underscores? Wouldn't iommu_deferred_attach_enabled
be a better name?
> - if (unlikely(iommu_dma_deferred_attach(dev, domain)))
> + if
On Tue, Nov 17, 2020 at 11:09:53AM +0100, Joerg Roedel wrote:
> Hi,
>
> last week I spent in the hospital and had an unplanned surgery from
> which I am recovering now. The recovery will take a few weeks, which
> unfortunatly does not allow me to fulfill my IOMMU maintainer duties or
> do any
On 2021-01-08 14:52, Jean-Philippe Brucker wrote:
The SMMU provides a Stall model for handling page faults in platform
devices. It is similar to PCIe PRI, but doesn't require devices to have
their own translation cache. Instead, faulting transactions are parked
and the OS is given a chance to
On Mon, Jan 18, 2021 at 1:39 PM Will Deacon wrote:
>
> On Mon, Jan 18, 2021 at 01:16:03PM -0800, Rob Clark wrote:
> > On Mon, Dec 21, 2020 at 4:44 PM Isaac J. Manjarres
> > wrote:
> > >
> > > The MSM DRM driver depends on the availability of the ARM LPAE io-pgtable
> > > format code to work
On 1/18/21 1:28 PM, Takashi Iwai wrote:
Hi,
we've got a bug report recently about the garbage playback sound from
a PCI sound device with mem_encrypt on AMD Ryzen:
On Wed, 2021-01-20 at 13:15 +0900, Tomasz Figa wrote:
> On Wed, Jan 13, 2021 at 3:45 PM Yong Wu wrote:
> >
> > On Wed, 2021-01-13 at 14:30 +0900, Tomasz Figa wrote:
> > > On Thu, Dec 24, 2020 at 8:35 PM Yong Wu wrote:
> > > >
> > > > On Wed, 2020-12-23 at 17:18 +0900, Tomasz Figa wrote:
> > > >
On 2021-01-11 19:45, Sai Prakash Ranjan wrote:
commit ecd7274fb4cd ("iommu: Remove unused IOMMU_SYS_CACHE_ONLY flag")
removed unused IOMMU_SYS_CACHE_ONLY prot flag and along with it went
the memory type setting required for the non-coherent masters to use
system cache. Now that system cache
On 1/19/21 10:37 PM, Chuck Lever wrote:
On Jan 18, 2021, at 8:22 PM, Lu Baolu wrote:
Do you mind posting the cap and ecap of the iommu used by your device?
You can get it via sysfs, for example:
/sys/bus/pci/devices/:00:14.0/iommu/intel-iommu# ls
address cap domains_supported
On 9/25/20 1:43 AM, Jarkko Sakkinen wrote:
> On Thu, Sep 24, 2020 at 10:58:33AM -0400, Ross Philipson wrote:
>> From: "Daniel P. Smith"
>>
>> This commit introduces an abstraction for TPM1.2 and TPM2.0 devices
>> above the TPM hardware interface.
>>
>> Signed-off-by: Daniel P. Smith
>>
Hi Jean,
On 1/19/21 6:16 PM, Jean-Philippe Brucker wrote:
On Mon, Jan 18, 2021 at 06:54:28AM +, Tian, Kevin wrote:
From: Lu Baolu
Sent: Saturday, January 16, 2021 11:54 AM
Hi Jean,
On 2021/1/15 0:41, Jean-Philippe Brucker wrote:
I guess detailing what's needed for nested IOPF can help
On 1/20/21 2:25 AM, Tina Zhang wrote:
irq_remapping_cap() was introduced to detect whether irq remapping
supports new features, such as VT-d Posted-Interrupts", according to
commit 959c870f7305 ("iommu, x86: Provide irq_remapping_cap() interface").
The VT-d Posted-Interrupts support can be
On 2021/1/19 20:32, Robin Murphy wrote:
> On 2021-01-19 01:59, Zhen Lei wrote:
>> Some SMMUv3 implementation embed the Perf Monitor Group Registers (PMCG)
>> inside the first 64kB region of the SMMU. Since SMMU and PMCG are managed
>> by two separate drivers, and this driver depends on
On Wed, Jan 13, 2021 at 3:45 PM Yong Wu wrote:
>
> On Wed, 2021-01-13 at 14:30 +0900, Tomasz Figa wrote:
> > On Thu, Dec 24, 2020 at 8:35 PM Yong Wu wrote:
> > >
> > > On Wed, 2020-12-23 at 17:18 +0900, Tomasz Figa wrote:
> > > > On Wed, Dec 09, 2020 at 04:00:41PM +0800, Yong Wu wrote:
> > > > >
Let's move out the is_kdump_kernel() check from iommu_dma_deferred_attach()
to iommu_dma_init(), and use the static-key in the fast-path to minimize
the impact in the normal case.
Signed-off-by: Lianbo Jiang
Co-developed-by: Robin Murphy
Signed-off-by: Robin Murphy
---
Currently, because domain attach allows to be deferred from iommu
driver to device driver, and when iommu initializes, the devices
on the bus will be scanned and the default groups will be allocated.
Due to the above changes, some devices could be added to the same
group as below:
[3.859417]
This patchset is to fix the failure of deferred attach for iommu attach
device, it includes the following two patches:
[1] [PATCH 1/2] dma-iommu: use static-key to minimize the impact in the
fast-path
This is a prepared patch for the second one, move out the is_kdump_kernel()
check from
On Fri, 8 Jan 2021 15:52:10 +0100
Jean-Philippe Brucker wrote:
> The pasid-num-bits property shouldn't need a dedicated fwspec field,
> it's a job for device properties. Add properties for IORT, and access
> the number of PASID bits using device_property_read_u32().
>
> Suggested-by: Robin
Hi Vivek,
On 1/15/21 1:13 PM, Vivek Gautam wrote:
> This patch-series aims at enabling Nested stage translation in guests
> using virtio-iommu as the paravirtualized iommu. The backend is supported
> with Arm SMMU-v3 that provides nested stage-1 and stage-2 translation.
>
> This series derives
irq_remapping_cap() was introduced to detect whether irq remapping
supports new features, such as VT-d Posted-Interrupts", according to
commit 959c870f7305 ("iommu, x86: Provide irq_remapping_cap() interface").
The VT-d Posted-Interrupts support can be disabled by the command
line parameter
Hi,
On Mon 18 Jan 21, 15:49, Robin Murphy wrote:
> On 2021-01-15 05:30, Yong Wu wrote:
> > On Thu, 2021-01-14 at 13:27 -0600, Rob Herring wrote:
> > > On Mon, Jan 11, 2021 at 07:18:47PM +0800, Yong Wu wrote:
> > > > "dev->dma_range_map" contains the devices' dma_ranges information,
> > > > This
On Mon, 2021-01-18 at 15:49 +, Robin Murphy wrote:
> On 2021-01-15 05:30, Yong Wu wrote:
> > On Thu, 2021-01-14 at 13:27 -0600, Rob Herring wrote:
> >> On Mon, Jan 11, 2021 at 07:18:47PM +0800, Yong Wu wrote:
> >>> "dev->dma_range_map" contains the devices' dma_ranges information,
> >>> This
Hi,
On Tue 19 Jan 21, 17:20, Yong Wu wrote:
> On Mon, 2021-01-18 at 15:49 +, Robin Murphy wrote:
> > On 2021-01-15 05:30, Yong Wu wrote:
> > > On Thu, 2021-01-14 at 13:27 -0600, Rob Herring wrote:
> > >> On Mon, Jan 11, 2021 at 07:18:47PM +0800, Yong Wu wrote:
> > >>> "dev->dma_range_map"
Hi Yi, Vivek,
On 1/13/21 6:56 AM, Liu, Yi L wrote:
> Hi Vivek,
>
>> From: Vivek Gautam
>> Sent: Tuesday, January 12, 2021 7:06 PM
>>
>> Hi Yi,
>>
>>
>> On Tue, Jan 12, 2021 at 2:51 PM Liu, Yi L wrote:
>>>
>>> Hi Vivek,
>>>
From: Vivek Gautam
Sent: Tuesday, January 12, 2021 2:50 PM
On Mon, Jan 18, 2021 at 06:54:28AM +, Tian, Kevin wrote:
> > From: Lu Baolu
> > Sent: Saturday, January 16, 2021 11:54 AM
> >
> > Hi Jean,
> >
> > On 2021/1/15 0:41, Jean-Philippe Brucker wrote:
> > > I guess detailing what's needed for nested IOPF can help the discussion,
> > > although I
The commit e0d072782c73 ("dma-mapping: introduce DMA range map,
supplanting dma_pfn_offset") always update dma_range_map even though it was
already set, like in the sunxi_mbus driver. the issue is reported at [1].
This patch avoid this(Updating it only when dev has valid dma-ranges).
Meanwhile,
On Fri, 8 Jan 2021 15:52:09 +0100
Jean-Philippe Brucker wrote:
> Commit 986d5ecc5699 ("iommu: Move fwspec->iommu_priv to struct
> dev_iommu") removed iommu_priv from fwspec. Update the struct doc.
>
> Signed-off-by: Jean-Philippe Brucker
Jonathan
> ---
> include/linux/iommu.h | 1 -
> 1
35 matches
Mail list logo
