n the SMMU for all STEs. Normal DMA
mappings will need to use TLBI_EL2 commands instead of TLBI_NH, but
shouldn't be otherwise affected by this change.
Acked-by: Will Deacon
Signed-off-by: Jean-Philippe Brucker
---
drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.h | 3 ++
drivers/iommu/arm/arm-s
[3]
https://lore.kernel.org/linux-iommu/20210121123623.2060416-1-jean-phili...@linaro.org/
[4]
https://lore.kernel.org/linux-pci/1610960316-28935-1-git-send-email-zhangfei@linaro.org/
Jean-Philippe Brucker (3):
iommu/arm-smmu-v3: Split arm_smmu_tlb_inv_range()
iommu/arm-smmu-v3: Make BTM op
On Thu, Jan 21, 2021 at 07:12:36PM +, Jonathan Cameron wrote:
> > @@ -2502,6 +2647,7 @@ static void arm_smmu_release_device(struct device
> > *dev)
> >
> > master = dev_iommu_priv_get(dev);
> > WARN_ON(arm_smmu_master_sva_enabled(master));
> > + iopf_queue_remove_device(master->smm
On ARM systems, some platform devices behind an IOMMU may support stall,
which is the ability to recover from page faults. Let the firmware tell us
when a device supports stall.
Reviewed-by: Rob Herring
Signed-off-by: Jean-Philippe Brucker
---
.../devicetree/bindings/iommu/iommu.txt
Copy the "Stall supported" bit, that tells whether a named component
supports stall, into the dma-can-stall device property.
Signed-off-by: Jean-Philippe Brucker
---
drivers/acpi/arm64/iort.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/acpi/arm6
Allow drivers to query and enable IOMMU_DEV_FEAT_IOPF, which amounts to
checking whether PRI is enabled.
Signed-off-by: Jean-Philippe Brucker
---
Cc: David Woodhouse
Cc: Lu Baolu
---
drivers/iommu/intel/iommu.c | 11 ---
1 file changed, 8 insertions(+), 3 deletions(-)
diff --git a
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.
Acked-by: Jonathan Cameron
Signed-off-by: Jean-Philippe Brucker
---
drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.h | 13 +-
drivers/iommu/arm/arm-smmu
which
initializes the fault queue for the device.
Tested-by: Zhangfei Gao
Signed-off-by: Jean-Philippe Brucker
---
drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.h | 43
.../iommu/arm/arm-smmu-v3/arm-smmu-v3-sva.c | 59 +-
drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c | 185
an Cameron
Signed-off-by: Jean-Philippe Brucker
---
drivers/iommu/Makefile| 1 +
drivers/iommu/iommu-sva-lib.h | 53
include/linux/iommu.h | 2 +
drivers/iommu/io-pgfault.c| 461 ++
4 files changed, 517 insertions(+)
create mode 1006
implementing a uacce interface doesn't need IOPF
support, it will need to tell the uacce module, for example with a new
flag.
Acked-by: Zhangfei Gao
Signed-off-by: Jean-Philippe Brucker
---
Cc: Arnd Bergmann
Cc: Greg Kroah-Hartman
Cc: Zhangfei Gao
Cc: Zhou Wang
---
drivers/misc/uacce/ua
phili...@linaro.org/
Jean-Philippe Brucker (10):
iommu: Fix comment for struct iommu_fwspec
iommu/arm-smmu-v3: Use device properties for pasid-num-bits
iommu: Separate IOMMU_DEV_FEAT_IOPF from IOMMU_DEV_FEAT_SVA
iommu/vt-d: Support IOMMU_DEV_FEAT_IOPF
uacce: Enable IOMMU_DEV_FEAT_IOPF
IOMMU_DEV_FEAT_IOPF on its own doesn't have any effect visible to the
device driver, it is used in combination with other features.
Signed-off-by: Jean-Philippe Brucker
---
Cc: Arnd Bergmann
Cc: David Woodhouse
Cc: Greg Kroah-Hartman
Cc: Joerg Roedel
Cc: Lu Baolu
Cc: Will Deacon
Cc: Zhangfe
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 Murphy
Acked-by: Jonathan Cameron
Signed-off-by: Jean-Philip
Commit 986d5ecc5699 ("iommu: Move fwspec->iommu_priv to struct
dev_iommu") removed iommu_priv from fwspec and commit 5702ee24182f
("ACPI/IORT: Check ATS capability in root complex nodes") added @flags.
Update the struct doc.
Acked-by: Jonathan Cameron
Signed-off-by
On Tue, Jan 19, 2021 at 05:28:21PM +, Robin Murphy wrote:
> On 2021-01-08 14:52, Jean-Philippe Brucker wrote:
> > +#define EVTQ_1_PRIV(1UL << 33)
> > +#define EVTQ_1_EXEC(1UL << 34)
> > +#define EVTQ_1_READ
On Tue, Jan 19, 2021 at 01:38:19PM +, Jonathan Cameron wrote:
> 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
On Tue, Jan 19, 2021 at 12:27:59PM +, Jonathan Cameron wrote:
> 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-sp
On Tue, Jan 19, 2021 at 11:11:44AM +, Jonathan Cameron wrote:
> 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
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 nes
On Mon, Jan 18, 2021 at 10:55:52AM +, John Garry wrote:
> On 18/01/2021 10:08, Jean-Philippe Brucker wrote:
> > > > Any idea why that's happening? This fix seems ok but if we're expecting
> > > > allocation failures for the loaded magazine then we could
On Mon, Jan 18, 2021 at 09:24:17AM +, John Garry wrote:
> On 15/01/2021 17:30, Jean-Philippe Brucker wrote:
> > On Thu, Dec 10, 2020 at 02:23:08AM +0800, John Garry wrote:
> > > A similar crash to the following could be observed if initial CPU rcache
> > > m
On Thu, Dec 10, 2020 at 02:23:09AM +0800, John Garry wrote:
> Leizhen reported some time ago that IOVA performance may degrade over time
> [0], but unfortunately his solution to fix this problem was not given
> attention.
>
> To summarize, the issue is that as time goes by, the CPU rcache and depo
On Thu, Dec 10, 2020 at 02:23:08AM +0800, John Garry wrote:
> A similar crash to the following could be observed if initial CPU rcache
> magazine allocations fail in init_iova_rcaches():
Any idea why that's happening? This fix seems ok but if we're expecting
allocation failures for the loaded mag
>
> Signed-off-by: John Garry
> Tested-by: Xiang Chen
> Reviewed-by: Zhen Lei
Reviewed-by: Jean-Philippe Brucker
(unless we find a better solution for patch 3)
> ---
> drivers/iommu/iova.c | 13 +
> 1 file changed, 9 insertions(+), 4 deletions(-)
>
> d
Hi Eric,
On Thu, Jan 14, 2021 at 05:58:27PM +0100, Auger Eric wrote:
> >> The uacce-devel branches from
> >>> https://github.com/Linaro/linux-kernel-uadk do provide this at the moment
> >>> (they track the latest sva/zip-devel branch
> >>> https://jpbrucker.net/git/linux/ which is roughly based o
On Wed, Jan 13, 2021 at 08:10:28AM +, Tian, Kevin wrote:
> > >> Is this only for SVA? We may see more scenarios of using IOPF. For
> > >> example, when passing through devices to user level, the user's pages
> > >> could be managed dynamically instead of being allocated and pinned
> > >> static
Hi Baolu,
On Tue, Jan 12, 2021 at 12:31:23PM +0800, Lu Baolu wrote:
> Hi Jean,
>
> On 1/8/21 10:52 PM, Jean-Philippe Brucker wrote:
> > Some devices manage I/O Page Faults (IOPF) themselves instead of relying
> > on PCIe PRI or Arm SMMU stall. Allow their drivers
the IOMMU retries the access.
The iopf_param pointer could be embedded into iommu_fault_param. But
putting iopf_param into the iommu_param structure allows us not to care
about ordering between calls to iopf_queue_add_device() and
iommu_register_device_fault_handler().
Signed-off-by: Jean-Philip
which
initializes the fault queue for the device.
Signed-off-by: Jean-Philippe Brucker
---
v9: Add IOMMU_DEV_FEAT_IOPF
---
drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.h | 61 ++
.../iommu/arm/arm-smmu-v3/arm-smmu-v3-sva.c | 70 ++-
drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
Allow drivers to query and enable IOMMU_DEV_FEAT_IOPF, which amounts to
checking whether PRI is enabled.
Signed-off-by: Jean-Philippe Brucker
---
Cc: David Woodhouse
Cc: Lu Baolu
---
drivers/iommu/intel/iommu.c | 11 ---
1 file changed, 8 insertions(+), 3 deletions(-)
diff --git a
Copy the "Stall supported" bit, that tells whether a named component
supports stall, into the dma-can-stall device property.
Signed-off-by: Jean-Philippe Brucker
---
v9: dropped fwspec member in favor of device properties
---
drivers/acpi/arm64/iort.c | 4 +++-
1 file changed, 3
On ARM systems, some platform devices behind an IOMMU may support stall,
which is the ability to recover from page faults. Let the firmware tell us
when a device supports stall.
Reviewed-by: Rob Herring
Signed-off-by: Jean-Philippe Brucker
---
.../devicetree/bindings/iommu/iommu.txt
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
---
drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.h | 13 +-
drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c | 161
implementing a uacce interface doesn't need IOPF
support, it will need to tell the uacce module, for example with a new
flag.
Signed-off-by: Jean-Philippe Brucker
---
Cc: Arnd Bergmann
Cc: Greg Kroah-Hartman
Cc: Zhangfei Gao
Cc: Zhou Wang
---
drivers/misc/uacce/uacce.c
: Jean-Philippe Brucker
---
Cc: Arnd Bergmann
Cc: David Woodhouse
Cc: Greg Kroah-Hartman
Cc: Joerg Roedel
Cc: Lu Baolu
Cc: Will Deacon
Cc: Zhangfei Gao
Cc: Zhou Wang
---
include/linux/iommu.h | 20 +---
1 file changed, 17 insertions(+), 3 deletions(-)
diff --git a/include
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 Murphy
Signed-off-by: Jean-Philippe Brucker
---
include/lin
ernel.org/linux-iommu/20201112125519.3987595-1-jean-phili...@linaro.org/
[2]
https://lore.kernel.org/linux-iommu/by5pr12mb3764f5d07e8ec48327e39c86b3...@by5pr12mb3764.namprd12.prod.outlook.com/
Jean-Philippe Brucker (10):
iommu: Remove obsolete comment
iommu/arm-smmu-v3: Use device properties for
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
---
include/linux/iommu.h | 1 -
1 file changed, 1 deletion(-)
diff --git a/include/linux/iommu.h b/include/linux/
Hi,
On Tue, Dec 15, 2020 at 01:09:29AM +, Krishna Reddy wrote:
> Hi Jean,
>
> > +bool arm_smmu_master_sva_supported(struct arm_smmu_master *master) {
> > + if (!(master->smmu->features & ARM_SMMU_FEAT_SVA))
> > + return false;
> +
> > + /* SSID and IOPF support are m
On Thu, Nov 26, 2020 at 06:09:26PM +, Robin Murphy wrote:
> On 2020-11-12 12:55, Jean-Philippe Brucker wrote:
> > Copy the dma-can-stall property into the fwspec structure.
>
> Can't we just handle this as a regular device property? It's not part of the
> actual
On Wed, Dec 09, 2020 at 07:49:09PM +, Krishna Reddy wrote:
> Hi Jean,
> > > Why is BTM mandated for SVA? I couldn't find this requirement in
> > > SMMU spec (Sorry if I missed it or this got discussed earlier). But
> > > if performance is the
> > only concern here,
> > > is it better just to
Hi,
On Thu, Dec 03, 2020 at 04:01:27PM -0700, Al Stone wrote:
> On 03 Dec 2020 22:21, Yinghan Yang wrote:
> > Hi Jean,
> >
> > I'm sorry for the delayed response. I think the new "PCI range node"
> > description makes sense. Could you please make this change in the proposal?
> >
> > Other than
Hi Shameer,
On Thu, Dec 03, 2020 at 06:42:57PM +, Shameerali Kolothum Thodi wrote:
> Hi Jean/zhangfei,
> Is it possible to have a branch with minimum required SVA/UACCE related
> patches
> that are already public and can be a "stable" candidate for future respin of
> Eric's series?
> Please
On Tue, Nov 24, 2020 at 07:58:00PM -0400, Jason Gunthorpe wrote:
> On Fri, Sep 18, 2020 at 12:18:52PM +0200, Jean-Philippe Brucker wrote:
>
> > +/* Allocate or get existing MMU notifier for this {domain, mm} pair */
> > +static struct arm_smmu_mmu_notifier *
> > +arm_smmu
eeded, the IOMMU retries the access.
The iopf_param pointer could be embedded into iommu_fault_param. But
putting iopf_param into the iommu_param structure allows us not to care
about ordering between calls to iopf_queue_add_device() and
iommu_register_device_fault_handler().
Signed-off-by: Jean-Philip
For PCI devices that support it, enable the PRI capability and handle
PRI Page Requests with the generic fault handler. It is enabled on
demand by iommu_sva_device_init().
Signed-off-by: Jean-Philippe Brucker
---
drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.h | 20 +-
.../iommu/arm/arm-smmu-v3
On ARM systems, some platform devices behind an IOMMU may support stall,
which is the ability to recover from page faults. Let the firmware tell us
when a device supports stall.
Reviewed-by: Rob Herring
Signed-off-by: Jean-Philippe Brucker
---
.../devicetree/bindings/iommu/iommu.txt
Copy the "Stall supported" bit, that tells whether a platform device
supports stall, into the fwspec struct.
Signed-off-by: Jean-Philippe Brucker
---
drivers/acpi/arm64/iort.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/acpi/arm64/iort.c b/drivers/acpi/arm64/io
nable stall for devices that support it (opt-in by firmware). When an
event corresponds to a translation error, call the IOMMU fault handler.
If the fault is recoverable, it will call us back to terminate or
continue the stall.
Signed-off-by: Jean-Philippe Brucker
---
v8:
* Extract firwmare se
Copy the dma-can-stall property into the fwspec structure.
Signed-off-by: Jean-Philippe Brucker
---
include/linux/iommu.h| 2 ++
drivers/iommu/of_iommu.c | 5 -
2 files changed, 6 insertions(+), 1 deletion(-)
diff --git a/include/linux/iommu.h b/include/linux/iommu.h
index a1c78c4cdeb1
When handling faults from the event or PRI queue, we need to find the
struct device associated to a SID. Add a rb_tree to keep track of SIDs.
Signed-off-by: Jean-Philippe Brucker
---
drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.h | 13 +-
drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c | 161
eviewed-by: Kuppuswamy Sathyanarayanan
Signed-off-by: Jean-Philippe Brucker
---
include/linux/pci-ats.h | 7 +++
1 file changed, 7 insertions(+)
diff --git a/include/linux/pci-ats.h b/include/linux/pci-ats.h
index df54cd5b15db..ccfca09fd232 100644
--- a/include/linux/pci-ats.h
+++ b/include
org/linux-iommu/20200519175502.2504091-1-jean-phili...@linaro.org/
[2]
https://lore.kernel.org/linux-iommu/20201106155048.997886-1-jean-phili...@linaro.org/
Jean-Philippe Brucker (9):
iommu: Add a page fault handler
iommu/arm-smmu-v3: Maintain a SID->device structure
dt-bindings: document stall
The SMMUv3 driver uses pci_{enable,disable}_pri() and related
functions. Export those functions to allow the driver to be built as a
module.
Acked-by: Bjorn Helgaas
Reviewed-by: Kuppuswamy Sathyanarayanan
Signed-off-by: Jean-Philippe Brucker
---
drivers/pci/ats.c | 4
1 file changed, 4
Hi Xiang,
Thank you for reviewing this. I forgot to send a reply, sorry for the
delay.
On Fri, May 29, 2020 at 05:18:27PM +0800, Xiang Zheng wrote:
> Hi,
>
> On 2020/5/20 1:54, Jean-Philippe Brucker wrote:
> > Some systems allow devices to handle I/O Page Faults in the core mm.
Hi Baolu,
Thanks for the review. I'm only now reworking this and realized I've never
sent a reply, sorry about that.
On Wed, May 20, 2020 at 02:42:21PM +0800, Lu Baolu wrote:
> Hi Jean,
>
> On 2020/5/20 1:54, Jean-Philippe Brucker wrote:
> > Some systems allow devices
ce last posting [1], only rebased onto v5.10-rc2.
Note that full SVA support for SMMUv3 still needs IOPF and DVM support,
coming soon.
[1]
https://lore.kernel.org/linux-iommu/20200918101852.582559-1-jean-phili...@linaro.org/
Jean-Philippe Brucker (4):
iommu/ioasid: Add ioasid references
Signed-off-by: Jean-Philippe Brucker
---
drivers/iommu/Kconfig | 2 +
drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.h | 28 +++
.../iommu/arm/arm-smmu-v3/arm-smmu-v3-sva.c | 230 +-
drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c | 32 ++-
4 files ch
_free().
Reviewed-by: Eric Auger
Reviewed-by: Lu Baolu
Signed-off-by: Jean-Philippe Brucker
---
include/linux/ioasid.h | 10 --
drivers/iommu/intel/iommu.c | 4 ++--
drivers/iommu/intel/svm.c | 6 +++---
drivers/iommu/ioasid.c | 38 +
4 files change
The invalidate_range() notifier is called for any change to the address
space. Perform the required ATC invalidations.
Signed-off-by: Jean-Philippe Brucker
---
drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.h| 2 ++
.../iommu/arm/arm-smmu-v3/arm-smmu-v3-sva.c| 16 +++-
drivers
Let IOMMU drivers allocate a single PASID per mm. Store the mm in the
IOASID set to allow refcounting and searching mm by PASID, when handling
an I/O page fault.
Reviewed-by: Lu Baolu
Signed-off-by: Jean-Philippe Brucker
---
drivers/iommu/Kconfig | 5 ++
drivers/iommu/Makefile
Hi Yinghan,
On Thu, Nov 05, 2020 at 10:05:28PM +, Yinghan Yang wrote:
> Thank you for the clarifications. In cases where a large range of PCI
> segments may be assigned to guest, would it make sense to describe this
> configuration as base + count. Currently, one would have to describe them
Hi,
On Thu, Nov 05, 2020 at 12:13:53AM +, Yinghan Yang via iommu wrote:
> Hi iommu developers,
>
>
>
> I have a question regarding the recent VIOT submission for supporting
> paravirtualized IOMMU in guests. The spec defines PCI Range Node Structure
> (5.2.30.3) that maps to a single PCI s
Hi Al,
On Tue, Nov 03, 2020 at 01:09:04PM -0700, Al Stone wrote:
> So, there are some questions about the VIOT definition and I just
> don't know enough to be able to answer them. One of the ASWG members
> is trying to understand the semantics behind the subtables.
Thanks for the update. We drop
On Fri, Oct 30, 2020 at 05:55:53AM +, Tian, Kevin wrote:
> > From: Lu Baolu
> > Sent: Friday, October 30, 2020 12:58 PM
> >
> > The aux-domain apis were designed for macro driver where the subdevices
> > are created and used inside a device driver. Use the device's bus iommu
> > ops instead o
On Mon, Oct 26, 2020 at 02:05:06PM -0700, Jacob Pan wrote:
> > This looks good to me, with small comments below.
> >
> Can I add your Reviewed-by tag after addressing the comments?
Yes sure, this took forever to review so I'm happy not to do another pass :)
> > > +Each IOASID set is created wit
Hi,
On Wed, Oct 28, 2020 at 09:36:57AM +0800, Yi Sun wrote:
> From: Jacob Pan
>
> original code fails when LAST_PAGE is set in flags.
LAST_PAGE is not documented to be a valid flags for page_response.
So isn't failing the right thing to do?
>
> Signed-off-by: Jacob Pan
> Signed-off-by: Liu Y
On Mon, Oct 19, 2020 at 02:16:08PM -0700, Raj, Ashok wrote:
> Hi Jean
>
> On Mon, Oct 19, 2020 at 04:08:24PM +0200, Jean-Philippe Brucker wrote:
> > On Sat, Oct 17, 2020 at 04:25:25AM -0700, Raj, Ashok wrote:
> > > > For devices that *don't* use a
On Mon, Oct 19, 2020 at 11:33:16AM -0700, Jacob Pan wrote:
> Hi Jean-Philippe,
>
> On Mon, 19 Oct 2020 16:08:24 +0200, Jean-Philippe Brucker
> wrote:
>
> > On Sat, Oct 17, 2020 at 04:25:25AM -0700, Raj, Ashok wrote:
> > > > For devices that *don't*
nb);
I think it's possible for ioasid_set_put_locked() to free the set right
after we release the lock, then this unregister() will be use-after-free.
Best keep holding the lock for this.
> + }
> + kfree(curr);
> + return;
> +
ter(&ioasid_notifier, nb);
> +}
> +EXPORT_SYMBOL_GPL(ioasid_register_notifier);
> +
Here as well, a comment saying that a reference to the set must be held,
though maybe that's obvious.
Thanks,
Jean
> +void ioasid_unregister_notifier(struct ioasid_set *set,
> + struct notifier_blo
On Mon, Sep 28, 2020 at 02:38:36PM -0700, Jacob Pan wrote:
> When an IOASID set is used for guest SVA, each VM will acquire its
> ioasid_set for IOASID allocations. IOASIDs within the VM must have a
> host/physical IOASID backing, mapping between guest and host IOASIDs can
> be non-identical. IOASI
gt; when the ioasid_set is freed, the user might perform the same cleanup
> operation on each IOASID.
>
> This patch adds an API to iterate all the IOASIDs within the set.
>
> Signed-off-by: Jacob Pan
Could add a short description of the function parameters, but
Reviewed-by: Jean-Philippe
On Mon, Sep 28, 2020 at 02:38:35PM -0700, Jacob Pan wrote:
> There can be multiple users of an IOASID, each user could have hardware
> contexts associated with the IOASID. In order to align lifecycles,
> reference counting is introduced in this patch. It is expected that when
> an IOASID is being f
() can
> then be used under spinlocks. In addition, this change makes the API
> symmetrical.
>
> Signed-off-by: Jacob Pan
A typo below, but
Reviewed-by: Jean-Philippe Brucker
> ---
> drivers/iommu/intel/svm.c | 4 ++--
> drivers/iommu/ioasid.c| 54
> +
SIDs already allocated within the set. The extra quota
> will be returned to the system-wide IOASID pool if the new quota is
> smaller than the existing one.
>
> Signed-off-by: Jacob Pan
Minor comments below, but
Reviewed-by: Jean-Philippe Brucker
> ---
>
On Mon, Sep 28, 2020 at 02:38:32PM -0700, Jacob Pan wrote:
> ioasid_set was introduced as an arbitrary token that is shared by a
> group of IOASIDs. For example, two IOASIDs allocated via the same
> ioasid_set pointer belong to the same set.
>
> For guest SVA usages, system-wide IOASID resources n
VT-d this is set during boot as part of the Intel IOMMU
> initialization.
>
> Signed-off-by: Jacob Pan
Reviewed-by: Jean-Philippe Brucker
> ---
> drivers/iommu/intel/iommu.c | 5 +
> drivers/iommu/ioasid.c | 20
> include/linux/ioasid.h |
On Mon, Sep 28, 2020 at 02:38:28PM -0700, Jacob Pan wrote:
> IOASID is used to identify address spaces that can be targeted by device
> DMA. It is a system-wide resource that is essential to its many users.
> This document is an attempt to help developers from all vendors navigate
> the APIs. At th
On Sat, Oct 17, 2020 at 04:25:25AM -0700, Raj, Ashok wrote:
> > For devices that *don't* use a stop marker, the PCIe spec says (10.4.1.2):
> >
> > To stop [using a PASID] without using a Stop Marker Message, the
> > function shall:
> > 1. Stop queueing new Page Request Messages for this PASI
On Thu, Oct 15, 2020 at 11:22:11AM -0700, Raj, Ashok wrote:
> Hi Jean
>
> + Baolu who is looking into this.
>
>
> On Thu, Oct 15, 2020 at 11:00:27AM +0200, Jean-Philippe Brucker wrote:
> > Add a parameter to iommu_sva_unbind_device() that tells the IOMMU driver
> &g
.
Add the IOMMU_UNBIND_FAULT_PENDING flags to unbind(), to tell the IOMMU
driver whether it's worth flushing the queue.
Signed-off-by: Jean-Philippe Brucker
---
include/linux/iommu.h | 31 +++
drivers/iommu/intel/svm.c | 3 ++-
drivers/iommu/iommu.c | 5
hould return whether faults are pending. This can be
added later once uacce has an actual PCIe user, but we need to
remember to do it.
Jean-Philippe Brucker (2):
iommu: Add flags to sva_unbind()
iommu: Add IOMMU_UNBIND_FAULT_PENDING flag
include/linux/intel-iommu.h | 2 +-
i
Provide a way for device drivers to tell IOMMU drivers about the device
state and the cleanup work to be done, when unbinding. No functional
change.
Signed-off-by: Jean-Philippe Brucker
---
include/linux/intel-iommu.h | 2 +-
include/linux/iommu.h | 7 ---
drivers/iommu/intel/svm.c
On Mon, Oct 12, 2020 at 08:38:54AM +, Tian, Kevin wrote:
> > From: Jason Wang
> > Sent: Monday, September 14, 2020 12:20 PM
> >
> [...]
> > If it's possible, I would suggest a generic uAPI instead of a VFIO
> > specific one.
> >
> > Jason suggest something like /dev/sva. There will be a lot
On Mon, Sep 28, 2020 at 10:43:26PM +, Fenghua Yu wrote:
> Hi, Will and Jean,
>
> On Mon, Sep 28, 2020 at 11:22:51PM +0100, Will Deacon wrote:
> > On Fri, Sep 18, 2020 at 12:18:41PM +0200, Jean-Philippe Brucker wrote:
> > > From: Fenghua Yu
> > >
> >
On Mon, Sep 28, 2020 at 11:39:02PM +0100, Will Deacon wrote:
> On Mon, Sep 28, 2020 at 06:23:15PM +0100, Will Deacon wrote:
> > On Mon, Sep 28, 2020 at 06:47:31PM +0200, Jean-Philippe Brucker wrote:
> > > On Fri, Sep 18, 2020 at 12:18:40PM +0200, Jean-Philippe Brucker wrot
Hi Will,
On Fri, Sep 18, 2020 at 12:18:40PM +0200, Jean-Philippe Brucker wrote:
> This is version 10 of the page table sharing support for Arm SMMUv3.
> Patch 1 still needs an Ack from mm maintainers. However patches 4-11 do
> not depend on it, and could get merged for v5.10 regardless.
On Fri, Sep 25, 2020 at 06:22:57AM -0400, Michael S. Tsirkin wrote:
> On Fri, Sep 25, 2020 at 10:48:06AM +0200, Jean-Philippe Brucker wrote:
> > On Fri, Aug 21, 2020 at 03:15:34PM +0200, Jean-Philippe Brucker wrote:
> > > Add a topology description to the virtio-iommu dri
in padding, flags, and version are also checked.
> Details are documented in Documentation/userspace-api/iommu.rst
>
> Signed-off-by: Liu Yi L
> Signed-off-by: Jacob Pan
Reviewed-by: Jean-Philippe Brucker
Some comments below in case you're resending,
On Fri, Aug 21, 2020 at 03:15:34PM +0200, Jean-Philippe Brucker wrote:
> Add a topology description to the virtio-iommu driver and enable x86
> platforms.
>
> Since [v2] we have made some progress on adding ACPI support for
> virtio-iommu, which is the preferred boot method on x8
On Thu, Sep 24, 2020 at 10:22:03AM -0500, Bjorn Helgaas wrote:
> On Fri, Aug 21, 2020 at 03:15:39PM +0200, Jean-Philippe Brucker wrote:
> > Platforms without device-tree nor ACPI can provide a topology
> > description embedded into the virtio config space. Parse it.
> >
>
On Thu, Sep 24, 2020 at 12:02:55PM +0200, Joerg Roedel wrote:
> On Thu, Sep 24, 2020 at 05:38:13AM -0400, Michael S. Tsirkin wrote:
> > On Thu, Sep 24, 2020 at 11:21:29AM +0200, Joerg Roedel wrote:
> > > On Thu, Sep 24, 2020 at 05:00:35AM -0400, Michael S. Tsirkin wrote:
> > > > OK so this looks go
Hi Shameer,
On Mon, Sep 21, 2020 at 08:59:39AM +, Shameerali Kolothum Thodi wrote:
> > +bool arm_smmu_sva_supported(struct arm_smmu_device *smmu)
> > +{
> > + unsigned long reg, fld;
> > + unsigned long oas;
> > + unsigned long asid_bits;
> > + u32 feat_mask = ARM_SMMU_FEAT_BTM |
> > A
On Fri, Sep 04, 2020 at 06:05:35PM +0200, Auger Eric wrote:
> > +static inline int viommu_pci_find_capability(struct pci_dev *dev, u8
> > cfg_type,
> > +struct viommu_cap_config *cap)
> not sure the inline is useful here
No, I'll drop it
Thanks,
Jean
_
On Fri, Sep 04, 2020 at 06:22:12PM +0200, Auger Eric wrote:
> > +/**
> > + * virt_dma_configure - Configure DMA of virtualized devices
> > + * @dev: the endpoint
> > + *
> > + * Setup the DMA and IOMMU ops of a virtual device, for platforms without
> > DT or
> > + * ACPI.
> > + *
> > + * Return: -
On Fri, Sep 18, 2020 at 04:02:26PM +0100, Robin Murphy wrote:
> On 2020-09-18 15:18, Jean-Philippe Brucker wrote:
> > When building with C=1, sparse reports some issues regarding endianness
> > annotations:
> >
> > arm-smmu-v3.c:221:26: warning: cast to restricted __le
]
strtab
arm-smmu-v3.c:1424:39:got restricted __le64 [usertype] *l2ptr
While harmless, they are incorrect and could hide actual errors during
development. Fix them.
Signed-off-by: Jean-Philippe Brucker
---
There is another false positive due to passing INT_MIN to cmpxchg, and
__cmpxchg* to
The invalidate_range() notifier is called for any change to the address
space. Perform the required ATC invalidations.
Signed-off-by: Jean-Philippe Brucker
---
drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.h| 2 ++
.../iommu/arm/arm-smmu-v3/arm-smmu-v3-sva.c| 16 +++-
drivers
_free().
Reviewed-by: Eric Auger
Reviewed-by: Lu Baolu
Signed-off-by: Jean-Philippe Brucker
---
include/linux/ioasid.h | 10 --
drivers/iommu/intel/iommu.c | 4 ++--
drivers/iommu/intel/svm.c | 6 +++---
drivers/iommu/ioasid.c | 38 +
4 files change
301 - 400 of 1703 matches
Mail list logo
