The VT-d IOMMU response RESPONSE_FAILURE for a page request in below
cases:
- When it gets a Page_Request with no PASID;
- When it gets a Page_Request with PASID that is not in use for this
device.
This is allowed by the spec, but IOMMU driver doesn't support such cases
today. When the device
It is incorrect to always clear PRO when it's set w/o first checking
whether the overflow condition has been cleared. Current code assumes
that if an overflow condition occurs it must have been cleared by earlier
loop. However since the code runs in a threaded context, the overflow
condition could
This includes some misc tweaks in the VT-d SVA implementation. I will
plan them for v5.12 if no objections.
Change log:
v1->v2:
- v1:
https://lore.kernel.org/linux-iommu/20210121014505.1659166-1-baolu...@linux.intel.com/
- Keep the logic of clearing PRO sane
- Drop the device
On 2021/1/25 23:47, Jason Gunthorpe wrote:
> On Mon, Jan 25, 2021 at 04:34:56PM +0800, Zhou Wang wrote:
>
>> +static int uacce_pin_page(struct uacce_pin_container *priv,
>> + struct uacce_pin_address *addr)
>> +{
>> +unsigned int flags = FOLL_FORCE | FOLL_WRITE;
>> +
On Mon, Jan 25, 2021 at 08:23:40PM +, Robin Murphy wrote:
> Now we probably will need some degreee of BBML feature awareness for the
> sake of SVA if and when we start using it for CPU pagetables, but I still
> cannot see any need to consider it in io-pgtable.
Agreed; I don't think this is
On 2021-01-25 21:52, Isaac J. Manjarres wrote:
When extracting the mask for a SMR that was programmed by the
bootloader, the SMR's valid bit is also extracted and is treated
as part of the mask, which is not correct. Consider the scenario
where an SMMU master whose context is determined by a
On 2021-01-25 21:51, Jordan Crouse wrote:
On Fri, Jan 22, 2021 at 12:53:17PM +, Robin Murphy wrote:
On 2021-01-22 12:41, Will Deacon wrote:
On Tue, Nov 24, 2020 at 12:15:58PM -0700, Jordan Crouse wrote:
Call report_iommu_fault() to allow upper-level drivers to register their
own fault
The device iommu probe/attach might have failed leaving dev->iommu
to NULL and device drivers may still invoke these functions resulting
a crash in iommu vendor driver code. Hence make sure we check that.
Signed-off-by: Shameer Kolothum
---
drivers/iommu/iommu.c | 8
1 file changed, 4
The MODULE_SOFTDEP() gives user space a hint of the loading sequence. And
when command "modprobe arm_smmuv3_pmu" is executed, the arm_smmu_v3.ko is
automatically loaded in advance.
Signed-off-by: Zhen Lei
---
drivers/perf/arm_smmuv3_pmu.c | 1 +
1 file changed, 1 insertion(+)
diff --git
According to the SMMUv3 specification:
Each PMCG counter group is represented by one 4KB page (Page 0) with one
optional additional 4KB page (Page 1), both of which are at IMPLEMENTATION
DEFINED base addresses.
This means that the PMCG register spaces may be within the 64KB pages of
the SMMUv3
v1 --> v2:
According to Robin Murphy's suggestion: https://lkml.org/lkml/2021/1/20/470
Don't reserve the PMCG register spaces, and reserve the entire SMMU register
space.
v1:
Since the PMCG may implement its resigters space(4KB Page0 and 4KB Page1)
within the SMMUv3 64KB Page0. In this case,
commit 52f3fab0067d ("iommu/arm-smmu-v3: Don't reserve implementation
defined register space") only reserves the basic SMMU register space. So
the ECMDQ register space is not covered, it should be mapped again. Due
to the size of this ECMDQ resource is not fixed, depending on
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
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
---
On Tue, 26 Jan 2021 13:06:29 +
Shameer Kolothum wrote:
> The device iommu probe/attach might have failed leaving dev->iommu
> to NULL and device drivers may still invoke these functions resulting
> a crash in iommu vendor driver code. Hence make sure we check that.
>
> Signed-off-by:
On 2021-01-26 11:53, 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
From: Nadav Amit
When an Intel IOMMU is virtualized, and a physical device is
passed-through to the VM, changes of the virtual IOMMU need to be
propagated to the physical IOMMU. The hypervisor therefore needs to
monitor PTE mappings in the IOMMU page-tables. Intel specifications
provide
On Tue, Jan 26, 2021 at 02:00:55PM +0800, Yong Wu wrote:
> This patch mainly support SMI modular. Switch MTK_SMI to tristate,
> and add module_exit/module_license.
>
> Signed-off-by: Yong Wu
> ---
> This patch rebase on the clean v5.11-rc1.
> and this one: memory: mtk-smi: Use
On Tue, Jan 26, 2021 at 01:26:45AM +, Song Bao Hua (Barry Song) wrote:
> > On Mon, Jan 25, 2021 at 11:35:22PM +, Song Bao Hua (Barry Song) wrote:
> >
> > > > On Mon, Jan 25, 2021 at 10:21:14PM +, Song Bao Hua (Barry Song)
> > > > wrote:
> > > > > mlock, while certainly be able to
From: Bjorn Helgaas
Fix misspellings of "physical".
Signed-off-by: Bjorn Helgaas
---
include/linux/intel-iommu.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/linux/intel-iommu.h b/include/linux/intel-iommu.h
index 09c6a0bf3892..3ae86385b222 100644
---
On 2021-01-26 16:40, Shameerali Kolothum Thodi wrote:
Hi Robin,
-Original Message-
From: Robin Murphy [mailto:robin.mur...@arm.com]
Sent: 26 January 2021 13:51
To: Shameerali Kolothum Thodi
Cc: linux-ker...@vger.kernel.org; iommu@lists.linux-foundation.org;
jean-phili...@linaro.org;
On 2021-01-25 19:31, Chuck Lever wrote:
On Jan 25, 2021, at 12:39 PM, Chuck Lever wrote:
Hello Lu -
Many thanks for your prototype.
On Jan 24, 2021, at 9:38 PM, Lu Baolu wrote:
This patch series is only for Request-For-Testing purpose. It aims to
fix the performance regression
On 2021-01-26 16:05, Rob Clark wrote:
On Tue, Jan 26, 2021 at 3:41 AM Robin Murphy wrote:
On 2021-01-25 21:51, Jordan Crouse wrote:
On Fri, Jan 22, 2021 at 12:53:17PM +, Robin Murphy wrote:
On 2021-01-22 12:41, Will Deacon wrote:
On Tue, Nov 24, 2020 at 12:15:58PM -0700, Jordan Crouse
Hi Robin,
> -Original Message-
> From: Robin Murphy [mailto:robin.mur...@arm.com]
> Sent: 26 January 2021 13:51
> To: Shameerali Kolothum Thodi
> Cc: linux-ker...@vger.kernel.org; iommu@lists.linux-foundation.org;
> jean-phili...@linaro.org; w...@kernel.org; linux...@openeuler.org;
On Tue, Jan 26, 2021 at 3:41 AM Robin Murphy wrote:
>
> On 2021-01-25 21:51, Jordan Crouse wrote:
> > On Fri, Jan 22, 2021 at 12:53:17PM +, Robin Murphy wrote:
> >> On 2021-01-22 12:41, Will Deacon wrote:
> >>> On Tue, Nov 24, 2020 at 12:15:58PM -0700, Jordan Crouse wrote:
> Call
Please take a quick look at this branch:
http://git.infradead.org/users/hch/misc.git/shortlog/refs/heads/dma_alloc_noncontiguous
Warning: hot off the press, and only with the v4l conversion as that
seemed at little easier than uvcvideo.
___
iommu
> On Jan 26, 2021, at 1:18 AM, Lu Baolu wrote:
>
> On 2021/1/26 3:31, Chuck Lever wrote:
>>> On Jan 25, 2021, at 12:39 PM, Chuck Lever wrote:
>>>
>>> Hello Lu -
>>>
>>> Many thanks for your prototype.
>>>
>>>
On Jan 24, 2021, at 9:38 PM, Lu Baolu wrote:
This patch series
Hi Robin-
> On Jan 26, 2021, at 11:05 AM, Robin Murphy wrote:
>
> Implementing .iotlb_sync_map means that a single top-level
> iommu_map()/iommu_map_sg() call should still only invoke a single "TLB flush"
> (really, any maintenance required for the IOMMU to start using the new
> mapping) at
On Mon, Jan 11, 2021 at 07:18:48PM +0800, Yong Wu wrote:
> If group->default_domain exists, avoid reallocate it.
>
> In some iommu drivers, there may be several devices share a group. Avoid
> realloc the default domain for this case.
>
> Signed-off-by: Yong Wu
> ---
> drivers/iommu/iommu.c | 3
Hi Christoph
Thanks for the series!
I have a couple of questions:
- Is there any platform where dma_alloc_noncontiguos can fail?
This is, !ops->alloc_noncontiguous and !dev->coherent_dma_mask
If yes then we need to add a function to let the driver know in
advance that it has to use the coherent
On 1/27/21 8:26 AM, Lu Baolu wrote:
+{
+ struct dmar_domain *dmar_domain = to_dmar_domain(domain);
+ struct intel_iommu *iommu = domain_get_iommu(dmar_domain);
+
+ if (intel_iommu_strict)
+ return 0;
+
+ /*
+ * The flush queue implementation does not perform page-selective
On Mon, Jan 11, 2021 at 07:18:41PM +0800, Yong Wu wrote:
> This patch mainly adds support for mt8192 Multimedia IOMMU and SMI.
>
> mt8192 also is MTK IOMMU gen2 which uses ARM Short-Descriptor translation
> table format. The M4U-SMI HW diagram is as below:
>
> EMI
>
Hi Nadav,
On 1/27/21 4:38 AM, Nadav Amit wrote:
From: Nadav Amit
When an Intel IOMMU is virtualized, and a physical device is
passed-through to the VM, changes of the virtual IOMMU need to be
propagated to the physical IOMMU. The hypervisor therefore needs to
monitor PTE mappings in the IOMMU
On Tue, Jan 26, 2021 at 02:54:01PM +1000, Nicholas Piggin wrote:
> vunmap will remove ptes.
Should there be some ASSERT after the vunmap to make sure that is the
case?
>
> Cc: Christoph Hellwig
> Cc: Marek Szyprowski
> Cc: Robin Murphy
> Cc: iommu@lists.linux-foundation.org
> Signed-off-by:
On Mon, 25 Jan 2021 13:52:25 -0800, Isaac J. Manjarres wrote:
> When extracting the mask for a SMR that was programmed by the
> bootloader, the SMR's valid bit is also extracted and is treated
> as part of the mask, which is not correct. Consider the scenario
> where an SMMU master whose context
From: Nadav Amit
When an Intel IOMMU is virtualized, and a physical device is
passed-through to the VM, changes of the virtual IOMMU need to be
propagated to the physical IOMMU. The hypervisor therefore needs to
monitor PTE mappings in the IOMMU page-tables. Intel specifications
provide
On Tue, Jan 26, 2021 at 05:08:46PM -0500, Konrad Rzeszutek Wilk wrote:
> On Tue, Jan 26, 2021 at 02:54:01PM +1000, Nicholas Piggin wrote:
> > vunmap will remove ptes.
>
> Should there be some ASSERT after the vunmap to make sure that is the
> case?
Not really. removing the PTEs is the whole
From: Wei Liu Sent: Wednesday, January 20, 2021 4:01 AM
>
> Just like MSI/MSI-X, IO-APIC interrupts are remapped by Microsoft
> Hypervisor when Linux runs as the root partition. Implement an IRQ
> domain to handle mapping and unmapping of IO-APIC interrupts.
>
> Signed-off-by: Wei Liu
> ---
>
> On Jan 26, 2021, at 4:26 PM, Lu Baolu wrote:
>
> Hi Nadav,
>
> On 1/27/21 4:38 AM, Nadav Amit wrote:
>> From: Nadav Amit
>> When an Intel IOMMU is virtualized, and a physical device is
>> passed-through to the VM, changes of the virtual IOMMU need to be
>> propagated to the physical IOMMU.
On 2021/1/27 10:01, Leizhen (ThunderTown) wrote:
>
>
> On 2021/1/26 18:12, Will Deacon wrote:
>> On Mon, Jan 25, 2021 at 08:23:40PM +, Robin Murphy wrote:
>>> Now we probably will need some degreee of BBML feature awareness for the
>>> sake of SVA if and when we start using it for CPU
I've sent another set of patches. https://lkml.org/lkml/2021/1/26/1065
If those patches are acceptable, then this one should be ignored.
On 2021/1/22 21:14, Zhen Lei wrote:
> No functional change.
>
> Signed-off-by: Zhen Lei
> ---
> drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c | 6 +-
> 1
> On Jan 26, 2021, at 8:53 PM, Lu Baolu wrote:
>
> Hi Chuck,
>
> On 1/26/21 11:52 PM, Chuck Lever wrote:
>>> On Jan 26, 2021, at 1:18 AM, Lu Baolu wrote:
>>>
>>> On 2021/1/26 3:31, Chuck Lever wrote:
> On Jan 25, 2021, at 12:39 PM, Chuck Lever wrote:
>
> Hello Lu -
>
Hi Chuck,
On 1/26/21 11:52 PM, Chuck Lever wrote:
On Jan 26, 2021, at 1:18 AM, Lu Baolu wrote:
On 2021/1/26 3:31, Chuck Lever wrote:
On Jan 25, 2021, at 12:39 PM, Chuck Lever wrote:
Hello Lu -
Many thanks for your prototype.
On Jan 24, 2021, at 9:38 PM, Lu Baolu wrote:
This patch
On 2021/1/26 18:12, Will Deacon wrote:
> On Mon, Jan 25, 2021 at 08:23:40PM +, Robin Murphy wrote:
>> Now we probably will need some degreee of BBML feature awareness for the
>> sake of SVA if and when we start using it for CPU pagetables, but I still
>> cannot see any need to consider it
45 matches
Mail list logo
