On 2020/5/27 11:27, Tian, Kevin wrote:
>> From: Xiang Zheng
>> Sent: Monday, May 25, 2020 7:34 PM
>>
>> [+cc Kirti, Yan, Alex]
>>
>> On 2020/5/23 1:14, Jean-Philippe Brucker wrote:
>>> Hi,
>>>
>>> On Tue, May 19, 2020 at 05:42:55PM +0800, Xiang Zheng wrote:
Hi all,
Is there any pla
From: Vijayanand Jitta
When ever an iova alloc request fails we free the iova
ranges present in the percpu iova rcaches and then retry
but the global iova rcache is not freed as a result we
could still see iova alloc failure even after retry as
global rcache is still holding the iova's which can
> From: Xiang Zheng
> Sent: Monday, May 25, 2020 7:34 PM
>
> [+cc Kirti, Yan, Alex]
>
> On 2020/5/23 1:14, Jean-Philippe Brucker wrote:
> > Hi,
> >
> > On Tue, May 19, 2020 at 05:42:55PM +0800, Xiang Zheng wrote:
> >> Hi all,
> >>
> >> Is there any plan for enabling SMMU HTTU?
> >
> > Not outside
Hi Jean,
This patch only enables HTTU bits in CDs. Is it also neccessary to enable
HTTU bits in STEs in this patch?
On 2020/5/20 1:54, Jean-Philippe Brucker wrote:
> If the SMMU supports it and the kernel was built with HTTU support,
> enable hardware update of access and dirty flags. This is ess
On 5/26/20 3:17 PM, Ashok Raj wrote:
All Intel platforms guarantee that all root complex implementations
must send transactions up to IOMMU for address translations. Hence for
RCiEP devices that are Vendor ID Intel, can claim exception for lack of
ACS support.
3.16 Root-Complex Peer to Peer C
On Tue, 26 May 2020 15:17:35 -0700
Ashok Raj wrote:
> All Intel platforms guarantee that all root complex implementations
> must send transactions up to IOMMU for address translations. Hence for
> RCiEP devices that are Vendor ID Intel, can claim exception for lack of
> ACS support.
>
>
> 3.16
Hello,
I'd like to use IOMMU perf counters on a Zen 2 CPU (Ryzen 4500U, Renoir SoC).
Unfortunately, init_iommu_perf_ctr fails because val2 != val, i.e. the
counter appears not writable. However, if I patch the kernel to skip this
check, the counters seem to increment when configured with perf tool
All Intel platforms guarantee that all root complex implementations
must send transactions up to IOMMU for address translations. Hence for
RCiEP devices that are Vendor ID Intel, can claim exception for lack of
ACS support.
3.16 Root-Complex Peer to Peer Considerations
When DMA remapping is enabl
Hello Andy,
On Tue, May 26, 2020 at 4:54 PM Andy Shevchenko
wrote:
>
> On Tue, May 26, 2020 at 03:12:48PM -0400, Jim Quinlan wrote:
> > The new field in struct device 'dma_pfn_offset_map' is used to facilitate
> > the use of multiple pfn offsets between cpu addrs and dma addrs. It is
> > similar
On Tue, May 26, 2020 at 03:12:48PM -0400, Jim Quinlan wrote:
> The new field in struct device 'dma_pfn_offset_map' is used to facilitate
> the use of multiple pfn offsets between cpu addrs and dma addrs. It is
> similar to 'dma_pfn_offset' except that the offset chosen depends on the
> cpu or dma
On Thu, May 14, 2020 at 12:34 PM wrote:
>
> On Thu 27 Feb 18:57 PST 2020, Bjorn Andersson wrote:
>
> Rob, Will, we're reaching the point where upstream has enough
> functionality that this is becoming a critical issue for us.
>
> E.g. Lenovo Yoga C630 is lacking this and a single dts patch to boot
The new field in struct device 'dma_pfn_offset_map' is used to facilitate
the use of multiple pfn offsets between cpu addrs and dma addrs. It is
similar to 'dma_pfn_offset' except that the offset chosen depends on the
cpu or dma address involved.
Signed-off-by: Jim Quinlan
---
drivers/of/addres
v2:
Commit: "device core: Add ability to handle multiple dma offsets"
o Added helper func attach_dma_pfn_offset_map() in address.c (Chistoph)
o Helpers funcs added to __phys_to_dma() & __dma_to_phys() (Christoph)
o Added warning when multiple offsets are needed and !DMA_PFN_OFFSET_MAP
o dev
From: Alexander Monakov
[ Upstream commit e461b8c991b9202b007ea2059d953e264240b0c9 ]
IVRS parsing code always tries to read 255 bytes from memory when
retrieving ACPI device path, and makes an assumption that firmware
provides a zero-terminated string. Both of those are bugs: the entry
is likely
From: Alexander Monakov
[ Upstream commit e461b8c991b9202b007ea2059d953e264240b0c9 ]
IVRS parsing code always tries to read 255 bytes from memory when
retrieving ACPI device path, and makes an assumption that firmware
provides a zero-terminated string. Both of those are bugs: the entry
is likely
From: Alexander Monakov
[ Upstream commit e461b8c991b9202b007ea2059d953e264240b0c9 ]
IVRS parsing code always tries to read 255 bytes from memory when
retrieving ACPI device path, and makes an assumption that firmware
provides a zero-terminated string. Both of those are bugs: the entry
is likely
From: Alexander Monakov
[ Upstream commit e461b8c991b9202b007ea2059d953e264240b0c9 ]
IVRS parsing code always tries to read 255 bytes from memory when
retrieving ACPI device path, and makes an assumption that firmware
provides a zero-terminated string. Both of those are bugs: the entry
is likely
From: Alexander Monakov
[ Upstream commit e461b8c991b9202b007ea2059d953e264240b0c9 ]
IVRS parsing code always tries to read 255 bytes from memory when
retrieving ACPI device path, and makes an assumption that firmware
provides a zero-terminated string. Both of those are bugs: the entry
is likely
On Tue, May 26, 2020 at 12:26:54PM -0600, Alex Williamson wrote:
> > >
> > > I don't think the language in the spec is anything sufficient to handle
> > > RCiEP uniquely. We've previously rejected kernel command line opt-outs
> > > for ACS, and the extent to which those patches still float around
On Tue, 26 May 2020 11:06:48 -0700
"Raj, Ashok" wrote:
> Hi Alex,
>
> I was able to find better language in the IOMMU spec that gaurantees
> the behavior we need. See below.
>
>
> On Tue, May 05, 2020 at 09:34:14AM -0600, Alex Williamson wrote:
> > On Tue, 5 May 2020 07:56:06 -0700
> > "Raj,
The intermediate result of the old term (4UL * 1024 * 1024 * 1024) is
4 294 967 296 or 0x1 which is no problem on 64 bit systems. The
patch does not change the later overall result of 0x10 for
MAX_DMA32_PFN. The new calculation yields the same result, but does not
require 64 bit arith
Hi Alex,
I was able to find better language in the IOMMU spec that gaurantees
the behavior we need. See below.
On Tue, May 05, 2020 at 09:34:14AM -0600, Alex Williamson wrote:
> On Tue, 5 May 2020 07:56:06 -0700
> "Raj, Ashok" wrote:
>
> > On Tue, May 05, 2020 at 08:05:14AM -0600, Alex Willia
Hi, Christoph
On 2020/5/26 下午10:46, Christoph Hellwig wrote:
On Tue, May 26, 2020 at 07:49:08PM +0800, Zhangfei Gao wrote:
Some platform devices appear as PCI but are actually on the AMBA bus,
and they need fixup in drivers/pci/quirks.c handling iommu_fwnode.
Here introducing PCI_FIXUP_IOMMU, w
On Tue, May 26, 2020 at 07:49:08PM +0800, Zhangfei Gao wrote:
> Some platform devices appear as PCI but are actually on the AMBA bus,
> and they need fixup in drivers/pci/quirks.c handling iommu_fwnode.
> Here introducing PCI_FIXUP_IOMMU, which is called after iommu_fwnode
> is allocated, instead o
On 2020/5/25 下午9:43, Joerg Roedel wrote:
On Tue, May 12, 2020 at 12:08:29PM +0800, Zhangfei Gao wrote:
Some platform devices appear as PCI but are
actually on the AMBA bus, and they need fixup in
drivers/pci/quirks.c handling iommu_fwnode.
So calling pci_fixup_final after iommu_fwnode is alloc
Calling pci_fixup_iommu in iommu_fwspec_init, which alloc
iommu_fwnode. Some platform devices appear as PCI but are
actually on the AMBA bus, and they need fixup in
drivers/pci/quirks.c handling iommu_fwnode.
So calling pci_fixup_iommu after iommu_fwnode is allocated.
Signed-off-by: Zhangfei Gao
Some platform devices appear as PCI but are actually on the AMBA bus,
and they need fixup in drivers/pci/quirks.c handling iommu_fwnode.
Here introducing PCI_FIXUP_IOMMU, which is called after iommu_fwnode
is allocated, instead of reusing PCI_FIXUP_FINAL since it will slow
down iommu probing as all
Some platform devices appear as PCI but are actually on the AMBA bus,
and they need fixup in drivers/pci/quirks.c handling iommu_fwnode.
Here introducing PCI_FIXUP_IOMMU, which is called after iommu_fwnode
is allocated, instead of reusing PCI_FIXUP_FINAL since it will slow
down iommu probing as all
On Tue, May 26, 2020 at 9:01 AM Marek Szyprowski
wrote:
>
> Hi
>
> On 13.05.2020 15:47, Christoph Hellwig wrote:
> > I've pushed out a branch with the first three patches here:
> >
> > git://git.infradead.org/users/hch/dma-mapping.git dma-sg_table-helper
> >
> > Gitweb:
> >
> >
> > http:/
On Mon, May 25, 2020 at 11:49:57PM +0200, Rikard Falkeborn wrote:
> The struct hyperv_ir_domain_ops is not modified and can be made const to
> allow the compiler to put it in read-only memory.
>
> Before:
>textdata bss dec hex filename
>29161180112052161460
On Mon, May 25, 2020 at 11:49:58PM +0200, Rikard Falkeborn wrote:
> The struct sun50i_iommu_ops is not modified and can be made const to
> allow the compiler to put it in read-only memory.
>
> Before:
>textdata bss dec hex filename
> 143582501 64 16923421b driv
On 2020-05-22 14:54, Robin Murphy wrote:
On 2020-05-22 07:25, gup...@codeaurora.org wrote:
On 2020-05-22 01:46, Robin Murphy wrote:
On 2020-05-21 12:30, Prakash Gupta wrote:
I agree, we shouldn't be freeing the partial iova. Instead just making
sure if unmap was successful should be sufficient
Hi
On 13.05.2020 15:47, Christoph Hellwig wrote:
> I've pushed out a branch with the first three patches here:
>
> git://git.infradead.org/users/hch/dma-mapping.git dma-sg_table-helper
>
> Gitweb:
>
>
> http://git.infradead.org/users/hch/dma-mapping.git/shortlog/refs/heads/dma-sg_table-he
33 matches
Mail list logo
