From: Julia Cartwright
[ Upstream commit cffaaf0c816238c45cd2d06913476c83eb50f682 ]
Commit 57384592c433 ("iommu/vt-d: Store bus information in RMRR PCI
device path") changed the type of the path data, however, the change in
path type was not reflected in size calculations. Update to use the
cor
From: Julia Cartwright
[ Upstream commit cffaaf0c816238c45cd2d06913476c83eb50f682 ]
Commit 57384592c433 ("iommu/vt-d: Store bus information in RMRR PCI
device path") changed the type of the path data, however, the change in
path type was not reflected in size calculations. Update to use the
cor
From: Julia Cartwright
[ Upstream commit cffaaf0c816238c45cd2d06913476c83eb50f682 ]
Commit 57384592c433 ("iommu/vt-d: Store bus information in RMRR PCI
device path") changed the type of the path data, however, the change in
path type was not reflected in size calculations. Update to use the
cor
From: Julia Cartwright
[ Upstream commit cffaaf0c816238c45cd2d06913476c83eb50f682 ]
Commit 57384592c433 ("iommu/vt-d: Store bus information in RMRR PCI
device path") changed the type of the path data, however, the change in
path type was not reflected in size calculations. Update to use the
cor
From: Julia Cartwright
[ Upstream commit cffaaf0c816238c45cd2d06913476c83eb50f682 ]
Commit 57384592c433 ("iommu/vt-d: Store bus information in RMRR PCI
device path") changed the type of the path data, however, the change in
path type was not reflected in size calculations. Update to use the
cor
From: Lu Baolu
[ Upstream commit 5bb71fc790a88d063507dc5d445ab8b14e845591 ]
The spec states in 10.4.16 that the Protected Memory Enable
Register should be treated as read-only for implementations
not supporting protected memory regions (PLMR and PHMR fields
reported as Clear in the Capability re
From: Lu Baolu
[ Upstream commit 5bb71fc790a88d063507dc5d445ab8b14e845591 ]
The spec states in 10.4.16 that the Protected Memory Enable
Register should be treated as read-only for implementations
not supporting protected memory regions (PLMR and PHMR fields
reported as Clear in the Capability re
From: Lu Baolu
[ Upstream commit 5bb71fc790a88d063507dc5d445ab8b14e845591 ]
The spec states in 10.4.16 that the Protected Memory Enable
Register should be treated as read-only for implementations
not supporting protected memory regions (PLMR and PHMR fields
reported as Clear in the Capability re
From: Lu Baolu
[ Upstream commit 5bb71fc790a88d063507dc5d445ab8b14e845591 ]
The spec states in 10.4.16 that the Protected Memory Enable
Register should be treated as read-only for implementations
not supporting protected memory regions (PLMR and PHMR fields
reported as Clear in the Capability re
From: Lu Baolu
[ Upstream commit 5bb71fc790a88d063507dc5d445ab8b14e845591 ]
The spec states in 10.4.16 that the Protected Memory Enable
Register should be treated as read-only for implementations
not supporting protected memory regions (PLMR and PHMR fields
reported as Clear in the Capability re
From: Lu Baolu
[ Upstream commit 84c11e4df5aa4955acaa441f0cf1cb2e50daf64b ]
The driver sets a default domain id (FLPT_DEFAULT_DID) in the
first level only pasid entry, but saves a different domain id
in @sdev->did. The value saved in @sdev->did will be used to
invalidate the translation caches.
From: Lu Baolu
[ Upstream commit 5bb71fc790a88d063507dc5d445ab8b14e845591 ]
The spec states in 10.4.16 that the Protected Memory Enable
Register should be treated as read-only for implementations
not supporting protected memory regions (PLMR and PHMR fields
reported as Clear in the Capability re
The pull request you sent on Fri, 29 Mar 2019 17:26:42 +0100:
> git://git.kernel.org/pub/scm/linux/kernel/git/joro/iommu.git
> tags/iommu-fixes-v5.1-rc3
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/c0b7f2a5fb957f2d5429b603b1a131ed7c8b4a30
Thank you!
--
Deet-doot-
On Fri, Mar 29, 2019 at 9:01 AM wrote:
>
> From: Laurentiu Tudor
>
> Prior to calling iommu_map()/iommu_unmap() page align the size or
> failures such as below could happen:
>
> iommu: unaligned: iova 0x... pa 0x... size 0x4000 min_pagesz 0x1
> qman_portal 5.qman-portal: failed to iom
On Fri, Mar 29, 2019 at 9:01 AM wrote:
>
> From: Laurentiu Tudor
>
> ARM SoCs use SMMU so the liodn fixup done in the qman driver is no
> longer making sense and it also breaks the ICID settings inherited
> from u-boot. Do the fixups only for PPC targets.
>
> Signed-off-by: Laurentiu Tudor
> ---
On Fri, Mar 29, 2019 at 9:19 AM Mukesh Ojha wrote:
> On 3/29/2019 4:29 AM, Jann Horn wrote:
> > The sparse checker attempts to ensure that all conversions between
> > fixed-endianness numbers and numbers with native endianness are explicit.
> > However, the calgary code reads and writes big-endian
On 2019-03-29 3:40 p.m., Jann Horn wrote:
> So what is the right thing to do in the context of
> arch/x86/kernel/pci-calgary_64.c? That code wants to perform MMIO with
> endianness conversion, and these accesses are always performed as
> MMIO. Using the non-atomic 64-bit I/O helpers for this wou
On Fri, Mar 29, 2019 at 10:32 PM Logan Gunthorpe wrote:
> On 2019-03-29 3:19 p.m., Jann Horn wrote:
> >>> Can the existing api's not be used here like iowrite64be/ioread64be/ or
> >>> similar variant in "include/asm-generic/io.h"
> >>
> >> Oooh! I didn't realize that those exist. I'll change that
On 2019-03-29 3:19 p.m., Jann Horn wrote:
>>> Can the existing api's not be used here like iowrite64be/ioread64be/ or
>>> similar variant in "include/asm-generic/io.h"
>>
>> Oooh! I didn't realize that those exist. I'll change that and send a v2.
Yes, they are very new! It took me a while to get
On Fri, Mar 29, 2019 at 9:03 AM wrote:
>
> From: Laurentiu Tudor
>
> Add a one-to-one iommu mapping for bman private data memory (FBPR).
> This is required for BMAN to work without faults behind an iommu.
>
> Signed-off-by: Laurentiu Tudor
> ---
> drivers/soc/fsl/qbman/bman_ccsr.c | 11
On 3/29/2019 12:29 PM, Robin Murphy wrote:
On 29/03/2019 10:51, Marc Gonzalez wrote:
On 28/03/2019 18:05, Marc Gonzalez wrote:
+
+ #global-interrupts = <0>;
+ interrupts =
+ ,
+ ,
+ ,
+ ,
+ ,
+
On Fri, Mar 29, 2019 at 10:19 PM Jann Horn wrote:
>
> +Logan Gunthorpe and Horia Geantă, since they've written a bunch of this code
>
> On Fri, Mar 29, 2019 at 5:48 PM Jann Horn wrote:
> > On Fri, Mar 29, 2019 at 9:19 AM Mukesh Ojha wrote:
> > > On 3/29/2019 4:29 AM, Jann Horn wrote:
> > > > The
+Logan Gunthorpe and Horia Geantă, since they've written a bunch of this code
On Fri, Mar 29, 2019 at 5:48 PM Jann Horn wrote:
> On Fri, Mar 29, 2019 at 9:19 AM Mukesh Ojha wrote:
> > On 3/29/2019 4:29 AM, Jann Horn wrote:
> > > The sparse checker attempts to ensure that all conversions between
On 29/03/2019 10:51, Marc Gonzalez wrote:
On 28/03/2019 18:05, Marc Gonzalez wrote:
ANOC1 SMMU filters PCIe accesses.
I'm not sure this description is entirely accurate...
ANOC likely stands for "Application Network-On-Chip"
arch/arm64/boot/dts/qcom/msm8998.dtsi | 15 +++
1
On Fri Mar 29 19, Joerg Roedel wrote:
From: Joerg Roedel
If a device has an exclusion range specified in the IVRS
table, this region needs to be reserved in the iova-domain
of that device. This hasn't happened until now and can cause
data corruption on data transfered with these devices.
Treat
On Fri, Mar 29, 2019 at 9:19 AM Mukesh Ojha wrote:
> On 3/29/2019 4:29 AM, Jann Horn wrote:
> > The sparse checker attempts to ensure that all conversions between
> > fixed-endianness numbers and numbers with native endianness are explicit.
> > However, the calgary code reads and writes big-endian
Hi Linus,
The following changes since commit 8c2ffd9174779014c3fe1f96d9dc3641d9175f00:
Linux 5.1-rc2 (2019-03-24 14:02:26 -0700)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/joro/iommu.git
tags/iommu-fixes-v5.1-rc3
for you to fetch changes up to 8a
Should this one go stable 4.14/4.19 too?
On Fri, 2019-03-29 at 16:00 +0200, laurentiu.tu...@nxp.com wrote:
>
> From: Laurentiu Tudor
>
> Fix issue with the entry indexing in the sg frame cleanup code being
> off-by-1. This problem showed up when doing some basic iperf tests and
> manifested i
On 3/29/19 10:10 AM, Joerg Roedel wrote:
> From: Joerg Roedel
>
> If a device has an exclusion range specified in the IVRS
> table, this region needs to be reserved in the iova-domain
> of that device. This hasn't happened until now and can cause
> data corruption on data transfered with these de
Hey Lu,
I’ve attached a preliminary v3, if you could take a look and run some tests
that would be great.
Since v2 i’ve added your default domain type patches, the new device_group
handler, and incorporated Jacob’s feedback.
> On 28 Mar 2019, at 18:37, James Sewart wrote:
>
> Hey Lu,
>
>> On
From: Joerg Roedel
If a device has an exclusion range specified in the IVRS
table, this region needs to be reserved in the iova-domain
of that device. This hasn't happened until now and can cause
data corruption on data transfered with these devices.
Treat exclusion ranges as reserved regions in
On 3/29/19 9:51 AM, Joerg Roedel wrote:
> Hi Gary,
>
> On Thu, Mar 28, 2019 at 02:52:19PM +, Gary R Hook wrote:
>> On 3/28/19 5:44 AM, Joerg Roedel wrote:
>>> + if (entry->prot & (1 << 2))
>>
>> Could we add #define IOMMU_WRITE_EXCL (1 << 2) to amd_iommu_types.h?
>
> Yes, I replace
Hi Gary,
On Thu, Mar 28, 2019 at 02:52:19PM +, Gary R Hook wrote:
> On 3/28/19 5:44 AM, Joerg Roedel wrote:
> > + if (entry->prot & (1 << 2))
>
> Could we add #define IOMMU_WRITE_EXCL (1 << 2) to amd_iommu_types.h?
Yes, I replace that magic number with a descriptive name.
> The pr
On 29/03/2019 14:00, laurentiu.tu...@nxp.com wrote:
From: Laurentiu Tudor
Add a one-to-one iommu mapping for bman private data memory (FBPR).
This is required for BMAN to work without faults behind an iommu.
Signed-off-by: Laurentiu Tudor
---
drivers/soc/fsl/qbman/bman_ccsr.c | 11 +
From: Laurentiu Tudor
The driver relies on the no longer valid assumption that dma addresses
(iovas) are identical to physical addressees and uses phys_to_virt() to
make iova -> vaddr conversions. Fix this also for scatter-gather frames
using the iova -> phys conversion function added in the prev
From: Laurentiu Tudor
Add an API that retrieves the 'struct device' that the specified fman
port probed against. The new API will be used in a subsequent iommu
enablement related patch.
Signed-off-by: Laurentiu Tudor
Acked-by: Madalin Bucur
---
drivers/net/ethernet/freescale/fman/fman_port.c
From: Laurentiu Tudor
Add a one-to-one iommu mapping for bman private data memory (FBPR).
This is required for BMAN to work without faults behind an iommu.
Signed-off-by: Laurentiu Tudor
---
drivers/soc/fsl/qbman/bman_ccsr.c | 11 +++
1 file changed, 11 insertions(+)
diff --git a/driv
From: Laurentiu Tudor
Add a couple of new APIs to check the probing status of the required
cpu bound qman and bman portals:
'int bman_portals_probed()' and 'int qman_portals_probed()'.
They return the following values.
* 1 if qman/bman portals were all probed correctly
* 0 if qman/bman porta
From: Laurentiu Tudor
Add a one-to-one iommu mapping for qman private data memory areas
(FQD and PFDR). This is required for QMAN to work without faults
behind an iommu.
Signed-off-by: Laurentiu Tudor
---
drivers/soc/fsl/qbman/qman_ccsr.c | 15 +++
1 file changed, 15 insertions(+)
From: Laurentiu Tudor
ARM SoCs use SMMU so the liodn fixup done in the qman driver is no
longer making sense and it also breaks the ICID settings inherited
from u-boot. Do the fixups only for PPC targets.
Signed-off-by: Laurentiu Tudor
---
drivers/soc/fsl/qbman/qman_ccsr.c | 2 ++
1 file chang
From: Laurentiu Tudor
Enabling SMMU altered the order of device probing causing the dpaa1
ethernet driver to get probed before qbman and causing a boot crash.
Add predictability in the probing order by deferring the ethernet
driver probe after qbman and portals by using the recently introduced
qb
From: Laurentiu Tudor
Prior to calling iommu_map()/iommu_unmap() page align the size or
failures such as below could happen:
iommu: unaligned: iova 0x... pa 0x... size 0x4000 min_pagesz 0x1
qman_portal 5.qman-portal: failed to iommu_map() -22
Seen when booted a kernel compiled with
From: Laurentiu Tudor
During probing, FMAN is reset thus losing all its register
settings. Backup port ICID registers before reset and restore
them after, similarly to how it's done on powerpc / PAMU based
platforms.
This also has the side effect of disabling the old code path
(liodn backup/resto
From: Laurentiu Tudor
Add a one-to-one iommu mapping for qman portal CENA register area.
This is required for QMAN stashing to work without faults behind
an iommu.
Signed-off-by: Laurentiu Tudor
---
drivers/soc/fsl/qbman/qman_portal.c | 17 +
1 file changed, 17 insertions(+)
d
From: Laurentiu Tudor
This patch series contains several fixes in preparation for SMMU
support on NXP LS1043A and LS1046A chips. Once these get picked up,
I'll submit the actual SMMU enablement patches consisting in the
required device tree changes.
This patch series contains only part of the pr
From: Laurentiu Tudor
The dma transactions initiator is the rx fman port so that's the device
that the dma mappings should be done. Previously the mappings were done
through the MAC device which makes no sense because it's neither dma-able
nor connected in any way to smmu.
Signed-off-by: Laurent
From: Laurentiu Tudor
Fix issue with the entry indexing in the sg frame cleanup code being
off-by-1. This problem showed up when doing some basic iperf tests and
manifested in traffic coming to a halt.
Signed-off-by: Laurentiu Tudor
Acked-by: Madalin Bucur
---
drivers/net/ethernet/freescale/d
From: Laurentiu Tudor
The driver relies on the no longer valid assumption that dma addresses
(iovas) are identical to physical addressees and uses phys_to_virt() to
make iova -> vaddr conversions. Fix this by adding a function that does
proper iova -> phys conversions using the iommu api and upda
Hi Robin,
Thanks a lot for detailed clarification.
I will send next patch set with the changes you suggested.
Regards,
Srinath.
On Thu, Mar 28, 2019 at 9:17 PM Robin Murphy wrote:
>
> On 28/03/2019 10:34, Srinath Mannam wrote:
> > Hi Robin,
> >
> > Thanks for your feedback. Please see my reply
On 28/03/2019 18:05, Marc Gonzalez wrote:
> ANOC1 SMMU filters PCIe accesses.
I'm not sure this description is entirely accurate...
ANOC likely stands for "Application Network-On-Chip"
> arch/arm64/boot/dts/qcom/msm8998.dtsi | 15 +++
> 1 file changed, 15 insertions(+)
>
> diff -
On 3/29/2019 4:29 AM, Jann Horn wrote:
The sparse checker attempts to ensure that all conversions between
fixed-endianness numbers and numbers with native endianness are explicit.
However, the calgary code reads and writes big-endian numbers from/to IO
memory using {read,write}{l,q}(), which re
51 matches
Mail list logo
