> From: Alex Williamson
> Sent: Wednesday, April 28, 2021 11:06 PM
>
> On Wed, 28 Apr 2021 06:34:11 +
> "Tian, Kevin" wrote:
>
> > > From: Jason Gunthorpe
> > > Sent: Monday, April 26, 2021 8:38 PM
> > >
> > [...]
> > > > Want to hear your opinion for one open here. There is no doubt that
> From: Jason Gunthorpe
> Sent: Wednesday, May 5, 2021 1:13 AM
>
> On Wed, Apr 28, 2021 at 06:58:19AM +, Tian, Kevin wrote:
> > > From: Jason Gunthorpe
> > > Sent: Wednesday, April 28, 2021 1:12 AM
> > >
> > [...]
> > > > As Alex says, if this line fails because of the group restrictions,
>
On Fri, May 07, 2021 at 07:36:49AM +, Tian, Kevin wrote:
> for /dev/ioasid there is still an open whether an process is allowed to
> open /dev/ioasid once or multiple times. If there is only one ioasid_fd
> per process, the accounting can be made accurately. otherwise the
> same problem still
On 2021-05-06 16:17, Steven Price wrote:
On 20/04/2021 09:27, Shameer Kolothum wrote:
From: Jon Nettleton
Check if there is any RMR info associated with the devices behind
the SMMU and if any, install bypass SMRs for them. This is to
keep any ongoing traffic associated with these devices
From: Kunkun Jiang
These features are essential to support dirty log tracking for
SMMU with io-pgtable mapping.
The dirty state information is encoded using the access permission
bits AP[2] (stage 1) or S2AP[1] (stage 2) in conjunction with the
DBM (Dirty Bit Modifier) bit, where DBM means
From: Kunkun Jiang
Block(largepage) mapping is not a proper granule for dirty log tracking.
Take an extreme example, if DMA writes one byte, under 1G mapping, the
dirty amount reported is 1G, but under 4K mapping, the dirty amount is
just 4K.
This splits block descriptor to an span of page
Some types of IOMMU are capable of tracking DMA dirty log, such as
ARM SMMU with HTTU or Intel IOMMU with SLADE. This introduces the
dirty log tracking framework in the IOMMU base layer.
Four new essential interfaces are added, and we maintaince the status
of dirty log tracking in iommu_domain.
Hi Robin, Will and everyone,
I think this series is relative mature now, please give your valuable
suggestions,
thanks!
This patch series is split from the series[1] that containes both IOMMU part and
VFIO part. The VFIO part will be sent out in another series.
[1]
From: Kunkun Jiang
During dirty log tracking, user will try to retrieve dirty log from
iommu if it supports hardware dirty log. Scan leaf TTD and treat it
is dirty if it's writable. As we just set DBM bit for stage1 mapping,
so check whether AP[2] is not set.
Co-developed-by: Keqian Zhu
From: Jean-Philippe Brucker
If the SMMU supports it and the kernel was built with HTTU support,
enable hardware update of access and dirty flags. This is essential for
shared page tables, to reduce the number of access faults on the fault
queue. Normal DMA with io-pgtables doesn't currently use
From: Kunkun Jiang
As nested mode is not upstreamed now, we just aim to support dirty
log tracking for stage1 with io-pgtable mapping (means not support
SVA mapping). If HTTU is supported, we enable HA/HD bits in the SMMU
CD and transfer ARM_HD quirk to io-pgtable.
Co-developed-by: Keqian Zhu
From: Kunkun Jiang
After dirty log is retrieved, user should clear dirty log to re-enable
dirty log tracking for these dirtied pages. This clears the dirty state
(As we just set DBM bit for stage1 mapping, so should set the AP[2] bit)
of these leaf TTDs that are specified by the user provided
From: Kunkun Jiang
This realizes clear_dirty_log iommu ops based on clear_dirty_log
io-pgtable ops.
Co-developed-by: Keqian Zhu
Signed-off-by: Kunkun Jiang
---
drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c | 25 +
1 file changed, 25 insertions(+)
diff --git
From: Kunkun Jiang
We have implemented these interfaces required to support iommu
dirty log tracking. The last step is reporting this feature to
upper user, then the user can perform higher policy base on it.
For arm smmuv3, it is equal to ARM_SMMU_FEAT_HD.
Co-developed-by: Keqian Zhu
From: Kunkun Jiang
This realizes switch_dirty_log. In order to get finer dirty
granule, it invokes arm_smmu_split_block when start dirty
log, and invokes arm_smmu_merge_page() to recover block
mapping when stop dirty log.
Co-developed-by: Keqian Zhu
Signed-off-by: Kunkun Jiang
---
From: Kunkun Jiang
This detects BBML feature and if SMMU supports it, transfer BBMLx
quirk to io-pgtable.
Co-developed-by: Keqian Zhu
Signed-off-by: Kunkun Jiang
---
drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c | 19 +++
drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.h | 6 ++
From: Kunkun Jiang
This realizes sync_dirty_log iommu ops based on sync_dirty_log
io-pgtable ops.
Co-developed-by: Keqian Zhu
Signed-off-by: Kunkun Jiang
---
drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c | 30 +
1 file changed, 30 insertions(+)
diff --git
From: Kunkun Jiang
If block(largepage) mappings are split during start dirty log, then
when stop dirty log, we need to recover them for better DMA performance.
This recovers block mappings and unmap the span of page mappings. BBML1
or BBML2 feature is required.
Merging page is designed to be
From: Xingang Wang
When request ACS for PCI device in of_iommu_configure, the pci device
has already been scanned and added with 'pci_acs_enable=0'. So the
pci_request_acs() in current procedure does not work for enabling ACS.
Besides, the ACS should be enabled only if there's an IOMMU in
From: Xingang Wang
When request ACS in of_iommu_configure, the pci_acs_init procedure has
already been called. The pci device probe procedure is like the following:
pci_host_common_probe
pci_device_add
pci_acs_init
of_iommu_configure
pci_request_acs
The pci_request_acs() does
Remove useless interrupt-names property for IOMMU node
Signed-off-by: Benjamin Gaignard
---
arch/arm/boot/dts/rk3036.dtsi | 1 -
1 file changed, 1 deletion(-)
diff --git a/arch/arm/boot/dts/rk3036.dtsi b/arch/arm/boot/dts/rk3036.dtsi
index 47a787a12e55..16753dc50bf3 100644
---
Remove useless interrupt-names properties for IOMMU nodes
Signed-off-by: Benjamin Gaignard
---
arch/arm64/boot/dts/rockchip/px30.dtsi | 2 --
1 file changed, 2 deletions(-)
diff --git a/arch/arm64/boot/dts/rockchip/px30.dtsi
b/arch/arm64/boot/dts/rockchip/px30.dtsi
index
Add '#" to iommu-cells properties.
Remove useless interrupt-names properties
Signed-off-by: Benjamin Gaignard
---
version 4:
- Remove interrupt-names properties from IOMMU nodes
arch/arm/boot/dts/rk322x.dtsi | 10 +++---
1 file changed, 3 insertions(+), 7 deletions(-)
diff --git
From: Simon Xue
RK356x SoC got new IOMMU hardware block (version 2).
Add a compatible to distinguish it from the first version.
Signed-off-by: Simon Xue
[Benjamin]
- port driver from kernel 4.19 to 5.12
- change functions prototype.
- squash all fixes in this commit.
Signed-off-by: Benjamin
This series adds the IOMMU driver for rk356x SoC.
Since a new compatible is needed to distinguish this second version of
IOMMU hardware block from the first one, it is an opportunity to convert
the binding to DT schema.
version 4:
- Add description for reg items
- Remove useless
Convert Rockchip IOMMU to DT schema
Signed-off-by: Benjamin Gaignard
---
version 4:
- Add descriptions for reg items
- Add description for interrupts items
- Remove useless interrupt-names proporties
version 2:
- Change maintainer
- Change reg maxItems
- Change interrupt maxItems
Add compatible for the second version of IOMMU hardware block.
RK356x IOMMU can also be link to a power domain.
Signed-off-by: Benjamin Gaignard
Reviewed-by: Rob Herring
---
version 3:
- Rename compatible with SoC name
version 2:
- Add power-domains property
On 2021-04-20 09:27, Shameer Kolothum wrote:
Get RMR regions associated with a dev reserved so that there is
a unity mapping for them in SMMU.
Signed-off-by: Shameer Kolothum
---
drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c | 29 +
1 file changed, 29 insertions(+)
diff
On 2021-05-04 09:41, Benjamin Gaignard wrote:
From: Simon Xue
RK356x SoC got new IOMMU hardware block (version 2).
Add a compatible to distinguish it from the first version.
Signed-off-by: Simon Xue
[Benjamin]
- port driver from kernel 4.19 to 5.12
- change functions prototype.
- squash all
On Fri, May 07, 2021 at 11:14:58AM -0700, Raj, Ashok wrote:
> On Fri, May 07, 2021 at 02:20:51PM -0300, Jason Gunthorpe wrote:
> > On Thu, May 06, 2021 at 09:32:40AM -0700, Raj, Ashok wrote:
> >
> > > For platforms that support ENQCMD, it is required to mandate PASIDs are
> > > global across the
On Fri, May 07, 2021 at 11:06:14AM -0600, Alex Williamson wrote:
> We had tossed around an idea of a super-container with vfio, it's maybe
> something we'd want to incorporate into this design. For instance, if
> memory could be pre-registered with a super container, which would
> handle the
On Fri, 07 May 2021 11:02:27 +0200, Benjamin Gaignard wrote:
> Convert Rockchip IOMMU to DT schema
>
> Signed-off-by: Benjamin Gaignard
> ---
> version 4:
> - Add descriptions for reg items
> - Add description for interrupts items
> - Remove useless interrupt-names proporties
>
> version 2:
On Fri, May 07, 2021 at 12:49:53PM +, Wang Xingang wrote:
> From: Xingang Wang
>
> When request ACS for PCI device in of_iommu_configure, the pci device
> has already been scanned and added with 'pci_acs_enable=0'. So the
> pci_request_acs() in current procedure does not work for enabling
Hi Jason,
On Fri, 7 May 2021 16:28:10 -0300, Jason Gunthorpe wrote:
> > The unanswered question is how do we plumb from vIOMMU without a custom
> > allocator to get a system wide PASID?
>
> PASID allocation is part of the iommu driver, it really shouldn't be
> global.
>
In the current
Hi all,
On 07/05/2021 22:00, osstest service owner wrote:
flight 161829 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/161829/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
[...]
test-arm64-arm64-examine
Hi Bjorn,
On 2021/5/8 5:14, Bjorn Helgaas wrote:
On Fri, May 07, 2021 at 12:49:53PM +, Wang Xingang wrote:
From: Xingang Wang
When request ACS for PCI device in of_iommu_configure, the pci device
has already been scanned and added with 'pci_acs_enable=0'. So the
pci_request_acs() in
> From: Jason Gunthorpe
> Sent: Thursday, April 29, 2021 4:46 AM
>
> > > I think the name IOASID is fine for the uAPI, the kernel version can
> > > be called ioasid_id or something.
> >
> > ioasid is already an id and then ioasid_id just adds confusion. Another
> > point is that ioasid is
This patch adds missing MODULE_DEVICE_TABLE definition which generates
correct modalias for automatic loading of this driver when it is built
as an external module.
Reported-by: Hulk Robot
Signed-off-by: Bixuan Cui
---
drivers/iommu/virtio-iommu.c | 1 +
1 file changed, 1 insertion(+)
diff
Hi Keqian,
On 5/7/21 6:21 PM, Keqian Zhu wrote:
Some types of IOMMU are capable of tracking DMA dirty log, such as
ARM SMMU with HTTU or Intel IOMMU with SLADE. This introduces the
dirty log tracking framework in the IOMMU base layer.
Four new essential interfaces are added, and we maintaince
On Fri, 7 May 2021 07:36:49 +
"Tian, Kevin" wrote:
> > From: Alex Williamson
> > Sent: Wednesday, April 28, 2021 11:06 PM
> >
> > On Wed, 28 Apr 2021 06:34:11 +
> > "Tian, Kevin" wrote:
> > >
> > > Can you or Alex elaborate where the complexity and performance problem
> > > locate in
On Thu, May 06, 2021 at 09:32:40AM -0700, Raj, Ashok wrote:
> For platforms that support ENQCMD, it is required to mandate PASIDs are
> global across the entire system. Maybe its better to call them gPASID for
> guest and hPASID for host. Short reason being gPASID->hPASID is a guest
> wide
On Fri, May 07, 2021 at 12:23:25PM -0700, Raj, Ashok wrote:
> Hi Jason
>
> - Removed lizefan's email due to bounces...
>
> On Fri, May 07, 2021 at 03:20:50PM -0300, Jason Gunthorpe wrote:
> > On Fri, May 07, 2021 at 11:14:58AM -0700, Raj, Ashok wrote:
> > > On Fri, May 07, 2021 at 02:20:51PM
On Fri, May 07, 2021 at 02:20:51PM -0300, Jason Gunthorpe wrote:
> On Thu, May 06, 2021 at 09:32:40AM -0700, Raj, Ashok wrote:
>
> > For platforms that support ENQCMD, it is required to mandate PASIDs are
> > global across the entire system. Maybe its better to call them gPASID for
> > guest and
Hi Jason
- Removed lizefan's email due to bounces...
On Fri, May 07, 2021 at 03:20:50PM -0300, Jason Gunthorpe wrote:
> On Fri, May 07, 2021 at 11:14:58AM -0700, Raj, Ashok wrote:
> > On Fri, May 07, 2021 at 02:20:51PM -0300, Jason Gunthorpe wrote:
> > > On Thu, May 06, 2021 at 09:32:40AM
44 matches
Mail list logo
