On 27/11/2018 18:53, Michael S. Tsirkin wrote:
> On Tue, Nov 27, 2018 at 06:10:46PM +0000, Jean-Philippe Brucker wrote:
>> On 27/11/2018 18:04, Michael S. Tsirkin wrote:
>>> On Tue, Nov 27, 2018 at 05:50:50PM +0000, Jean-Philippe Brucker wrote:
>>>> On 23/11/2018 2
Sorry for the delay, I wanted to do a little more performance analysis
before continuing.
On 27/11/2018 18:10, Michael S. Tsirkin wrote:
> On Tue, Nov 27, 2018 at 05:55:20PM +0000, Jean-Philippe Brucker wrote:
>>>> + if (!virtio_has_feature(vdev, VIR
On 27/11/2018 18:04, Michael S. Tsirkin wrote:
> On Tue, Nov 27, 2018 at 05:50:50PM +0000, Jean-Philippe Brucker wrote:
>> On 23/11/2018 22:02, Michael S. Tsirkin wrote:
>>>> +/*
>>>> + * __viommu_sync_req - Complete all in-flight requests
>>>> + *
>
On 23/11/2018 21:48, Michael S. Tsirkin wrote:
>> +struct virtio_iommu_config {
>> +/* Supported page sizes */
>> +__u64 page_size_mask;
>> +/* Supported IOVA range */
>> +struct virtio_iommu_range input_range;
>> +/* Max domain ID
On 23/11/2018 21:56, Michael S. Tsirkin wrote:
>> +config VIRTIO_IOMMU
>> +bool "Virtio IOMMU driver"
>> +depends on VIRTIO=y
>> +select IOMMU_API
>> +select INTERVAL_TREE
>> +select ARM_DMA_USE_IOMMU if ARM
>> +help
>> + Para-virtualised IOMMU driver with virtio.
>> +
On 23/11/2018 22:02, Michael S. Tsirkin wrote:
>> +/*
>> + * __viommu_sync_req - Complete all in-flight requests
>> + *
>> + * Wait for all added requests to complete. When this function returns, all
>> + * requests that were in-flight at the time of the call have completed.
>> + */
>> +static int
The event queue offers a way for the device to report access faults from
endpoints. It is implemented on virtqueue #1. Whenever the host needs to
signal a fault, it fills one of the buffers offered by the guest and
interrupts it.
Reviewed-by: Eric Auger
Signed-off-by: Jean-Philippe Brucker
corresponding virtio requests. Mappings are kept in an interval tree
instead of page tables.
Signed-off-by: Jean-Philippe Brucker
---
MAINTAINERS | 7 +
drivers/iommu/Kconfig | 11 +
drivers/iommu/Makefile| 1 +
drivers/iommu/virtio-iommu.c | 916
virtio-iommu, because MSIs bypass it.
Reviewed-by: Eric Auger
Signed-off-by: Jean-Philippe Brucker
---
drivers/iommu/virtio-iommu.c | 156 --
include/uapi/linux/virtio_iommu.h | 38
2 files changed, 188 insertions(+), 6 deletions(-)
diff --git a/drivers
ed-by: Rob Herring
Signed-off-by: Jean-Philippe Brucker
---
drivers/of/base.c | 10 +++---
1 file changed, 7 insertions(+), 3 deletions(-)
diff --git a/drivers/of/base.c b/drivers/of/base.c
index 09692c9b32a7..99f6bfa9b898 100644
--- a/drivers/of/base.c
+++ b/drivers/of/base.c
@@ -2237,8 +2237
For PCI devices that have an OF node, set the fwnode as well. This way
drivers that rely on fwnode don't need the special case described by
commit f94277af03ea ("of/platform: Initialise dev->fwnode appropriately").
Acked-by: Bjorn Helgaas
Signed-off-by: Jean-Philippe Brucker
rwise, the virtio-mmio device may perform DMA through an IOMMU, which
requires an "iommus" property. Describe these requirements in the
device-tree bindings documentation.
Reviewed-by: Rob Herring
Reviewed-by: Eric Auger
Signed-off-by: Jean-Philippe Brucker
---
.../devicetree/bind
Reviewed-by: Rob Herring
Reviewed-by: Eric Auger
Signed-off-by: Jean-Philippe Brucker
---
.../devicetree/bindings/virtio/iommu.txt | 66 +++
1 file changed, 66 insertions(+)
create mode 100644 Documentation/devicetree/bindings/virtio/iommu.txt
diff --git a/Documentation/d
-jpb.git virtio-iommu/v0.9
[4] [RFC v9 00/17] VIRTIO-IOMMU device
https://www.mail-archive.com/qemu-devel@nongnu.org/msg575578.html
Jean-Philippe Brucker (7):
dt-bindings: virtio-mmio: Add IOMMU description
dt-bindings: virtio: Add virtio-pci-iommu node
of: Allow the iommu-map propert
On 22/11/2018 08:44, Joerg Roedel wrote:
> Hi Jean-Philippe,
>
> On Wed, Nov 21, 2018 at 11:16:07AM +0000, Jean-Philippe Brucker wrote:
>> On 12/11/2018 14:40, Joerg Roedel wrote:
>>> What is the intended use-case for this function?
>>
>> I'm using it in s
On 12/11/2018 14:55, j...@8bytes.org wrote:
> Hi Jean-Philippe,
>
> On Thu, Nov 08, 2018 at 06:29:42PM +0000, Jean-Philippe Brucker wrote:
>> (1) My initial approach would have been to use the same page tables for
>> the default_domain and this new domain, but it might be
On 12/11/2018 14:40, Joerg Roedel wrote:
> Hi Jean-Philippe,
>
> On Fri, Oct 19, 2018 at 07:11:54PM +0100, Jean-Philippe Brucker wrote:
>> The allocator doesn't really belong in drivers/iommu because some
>> drivers would like to allocate PASIDs for devices that are
On 16/11/2018 18:46, Jean-Philippe Brucker wrote:
>>> +/*
>>> + * __viommu_sync_req - Complete all in-flight requests
>>> + *
>>> + * Wait for all added requests to complete. When this function returns, all
>>> + * requests that were in-
On 20/11/2018 09:16, Jonathan Cameron wrote:
> +CC Jean-Phillipe and iommu list.
Thanks for the Cc, sorry I don't have enough bandwidth to follow this
thread at the moment.
> In WarpDrive/uacce, we make this simple. If you support IOMMU and it
> support
> SVM/SVA. Everything will be
Hi Eric,
On 16/11/2018 06:08, Auger Eric wrote:
>> +struct viommu_domain {
>> +struct iommu_domain domain;
>> +struct viommu_dev *viommu;
>> +struct mutexmutex;
> same naming/comment as in smmu driver may help here
> struct mutex
For PCI devices that have an OF node, set the fwnode as well. This way
drivers that rely on fwnode don't need the special case described by
commit f94277af03ea ("of/platform: Initialise dev->fwnode appropriately").
Acked-by: Bjorn Helgaas
Signed-off-by: Jean-Philippe Brucker
f-by: Jean-Philippe Brucker
---
drivers/of/base.c | 10 +++---
1 file changed, 7 insertions(+), 3 deletions(-)
diff --git a/drivers/of/base.c b/drivers/of/base.c
index 09692c9b32a7..99f6bfa9b898 100644
--- a/drivers/of/base.c
+++ b/drivers/of/base.c
@@ -2237,8 +2237,12 @@ int of_map_
virtio-iommu, because MSIs bypass it.
Signed-off-by: Jean-Philippe Brucker
---
drivers/iommu/virtio-iommu.c | 156 --
include/uapi/linux/virtio_iommu.h | 38
2 files changed, 188 insertions(+), 6 deletions(-)
diff --git a/drivers/iommu/virtio-iommu.c b
The event queue offers a way for the device to report access faults from
endpoints. It is implemented on virtqueue #1. Whenever the host needs to
signal a fault, it fills one of the buffers offered by the guest and
interrupts it.
Signed-off-by: Jean-Philippe Brucker
---
drivers/iommu/virtio
corresponding virtio requests. Mappings are kept in an interval tree
instead of page tables.
Signed-off-by: Jean-Philippe Brucker
---
MAINTAINERS | 7 +
drivers/iommu/Kconfig | 11 +
drivers/iommu/Makefile| 1 +
drivers/iommu/virtio-iommu.c | 918
Reviewed-by: Rob Herring
Reviewed-by: Eric Auger
Signed-off-by: Jean-Philippe Brucker
---
.../devicetree/bindings/virtio/iommu.txt | 66 +++
1 file changed, 66 insertions(+)
create mode 100644 Documentation/devicetree/bindings/virtio/iommu.txt
diff --git a/Documentation/d
1
[4] [RFC v8 00/18] VIRTIO-IOMMU device
https://www.mail-archive.com/qemu-devel@nongnu.org/msg572637.html
Jean-Philippe Brucker (7):
dt-bindings: virtio-mmio: Add IOMMU description
dt-bindings: virtio: Add virtio-pci-iommu node
of: Allow the iommu-map property to omit untranslated devices
rwise, the virtio-mmio device may perform DMA through an IOMMU, which
requires an "iommus" property. Describe these requirements in the
device-tree bindings documentation.
Reviewed-by: Rob Herring
Reviewed-by: Eric Auger
Signed-off-by: Jean-Philippe Brucker
---
.../devicetree/bind
Fixed all of these, thanks
Jean
On 15/11/2018 13:20, Auger Eric wrote:
> Hi Jean,
> On 10/12/18 4:59 PM, Jean-Philippe Brucker wrote:
>> When the device offers the probe feature, send a probe request for each
>> device managed by the IOMMU. Extract RESV_MEM information. When
On 07/11/2018 04:53, Lu Baolu wrote:
> Hi,
>
> On 10/20/18 2:11 AM, Jean-Philippe Brucker wrote:
>> +static inline void *ioasid_find(struct ioasid_set *set, ioasid_t ioasid)
>> +{
>> +return -ESRCH;
>
> return
Hi,
On 06/11/2018 16:25, j...@8bytes.org wrote:
> On Mon, Oct 22, 2018 at 12:50:56PM +0100, Robin Murphy wrote:
>> To me, that sounds like a very good argument for having separate "attach as
>> primary domain" and "attach as aux domain" APIs.
>
> I agree with that, overloading iommu_attach_device
On 08/11/2018 14:51, Auger Eric wrote:
>>> +/*
>>> + * viommu_replay_mappings - re-send MAP requests
>>> + *
>>> + * When reattaching a domain that was previously detached from all
>>> endpoints,
>>> + * mappings were deleted from the device. Re-create the mappings available
>>> in
>>> + * the in
On 08/11/2018 14:48, Auger Eric wrote:
>> +struct virtio_iommu_probe_property {
>> +__le16 type;
>> +__le16 length;
> the value[] field has disappeared but still is documented in the v0.8 spec.
Good catch. I removed value[]
On 22/10/2018 12:50, Robin Murphy wrote:
> To me, that sounds like a very good argument for having separate "attach
> as primary domain" and "attach as aux domain" APIs. Say a driver wants
> to use multiple aux domains itself to isolate logically-separate
> transaction streams, but still also needs
On 22/10/2018 11:07, Raj, Ashok wrote:
>> For my own convenience I've been using the SVA infrastructure since
>> I already had the locking and IOMMU ops in place. The proposed
>> interface is also missing min_pasid and max_pasid parameters, which
>> could be needed by device drivers
On 17/10/2018 16:14, Michael S. Tsirkin wrote:
>>> Thinking about this comment, I would like to ask: can't the
>>> virtio device indicate the ranges in a portable way?
>>> This would minimize the dependency on dt bindings and ACPI,
>>> enabling support for systems that have neither but do
>>> have
Allow device driver to create PASID contexts by setting a device in
'auxiliary' mode and allocating new domains. Each domain corrsponds to a
PASID.
Signed-off-by: Jean-Philippe Brucker
---
drivers/iommu/arm-smmu-v3.c | 157 ++--
1 file changed, 151
Add IOMMU_SVA_FEAT_AUXD and small helpers to SVA, to setup PASID with
the sva_init_device() IOMMU op and allocate PASIDs.
Signed-off-by: Jean-Philippe Brucker
---
drivers/iommu/iommu-sva.c | 33 -
include/linux/iommu.h | 12
2 files changed, 44
To prepare for auxiliary domains, add detach_dev() to the IOMMU ops.
There shouldn't be any functional change.
Signed-off-by: Jean-Philippe Brucker
---
drivers/iommu/arm-smmu-v3.c | 9 +
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/drivers/iommu/arm-smmu-v3.c b/dr
IOMMU. It doesn't really belong in
drivers/pci either since platform device also support PASID. Add the
allocator in drivers/base.
Signed-off-by: Jean-Philippe Brucker
---
drivers/base/Kconfig | 7 +++
drivers/base/Makefile | 1 +
drivers/base/
Now that the IOASID allocator is in place, use it to allocate shared
PASIDs.
Signed-off-by: Jean-Philippe Brucker
---
drivers/iommu/Kconfig | 1 +
drivers/iommu/iommu-sva.c | 80 ++-
2 files changed, 46 insertions(+), 35 deletions(-)
diff --git a
ivers that don't support auxiliary domains are also affected by
the change in (3). Those that support default_domain now get
detach_dev() followed by attach_dev() callback on iommu_detach_device(),
instead of just attach_dev().
Signed-off-by: Jean-Philippe Brucker
---
drivers/iommu/iommu.c
-jpb.git iommu/auxd
[1] [PATCH v3 0/8] vfio/mdev: IOMMU aware mediated device
https://lwn.net/ml/linux-kernel/20181012051632.26064-1-baolu...@linux.intel.com/
[2] [PATCH v3 00/10] Shared Virtual Addressing for the IOMMU
https://www.spinics.net/lists/iommu/msg30076.html
Jean-Philippe
On 17/10/2018 15:21, Jean-Philippe Brucker wrote:
> Hi Jordan,
>
> On 12/10/2018 15:32, Jordan Crouse wrote:
>> On Thu, Sep 20, 2018 at 06:00:46PM +0100, Jean-Philippe Brucker wrote:
>>> Provide an API for allocating PASIDs and populating them manually. To ease
>>&
Hi Jordan,
On 12/10/2018 15:32, Jordan Crouse wrote:
> On Thu, Sep 20, 2018 at 06:00:46PM +0100, Jean-Philippe Brucker wrote:
>> Provide an API for allocating PASIDs and populating them manually. To ease
>> cleanup and factor allocation code, reuse the io_mm structure for p
On 16/10/2018 21:31, Auger Eric wrote:
> Hi Jean,
>
> On 10/16/18 8:44 PM, Jean-Philippe Brucker wrote:
>> On 16/10/2018 10:25, Auger Eric wrote:
>>> Hi Jean,
>>>
>>> On 10/12/18 4:59 PM, Jean-Philippe Brucker wrote:
>>>> Implement th
On 16/10/2018 10:25, Auger Eric wrote:
> Hi Jean,
>
> On 10/12/18 4:59 PM, Jean-Philippe Brucker wrote:
>> Implement the virtio-iommu driver, following specification v0.8 [1].
>> Changes since v2 [2]:
>>
>> * Patches 2-4 allow virtio-iommu to use the PCI transpo
[Replying with my personal address because we're having SMTP issues]
On 15/10/2018 11:52, Michael S. Tsirkin wrote:
> On Fri, Oct 12, 2018 at 02:41:59PM -0500, Bjorn Helgaas wrote:
>> s/iommu/IOMMU/ in subject
>>
>> On Fri, Oct 12, 2018 at 03:59:13PM +0100, Jean-Philipp
[Replying with my personal address because we're having SMTP issues]
On 12/10/2018 20:41, Bjorn Helgaas wrote:
> s/iommu/IOMMU/ in subject
>
> On Fri, Oct 12, 2018 at 03:59:13PM +0100, Jean-Philippe Brucker wrote:
>> Using the iommu-map binding, endpoints in a given PCI doma
On 12/10/2018 18:00, Michael S. Tsirkin wrote:
> This all looks good to me. Minor nits:
> - I think DEBUG mode is best just removed for now
> - Slightly wrong patch splitup causing a misaligned structure
> in uapi until all patches are applied.
Thanks a lot for the review, I'll fix these up and
On 12/10/2018 17:35, Michael S. Tsirkin wrote:
>> +list_del(&req->list);
>> +kfree(req);
>
> So with DEBUG set, this will actually free memory that device still
> DMA's into. Hardly pretty. I think you want to mark device broken,
> queue the request and then wait for device
The event queue offers a way for the device to report access faults from
endpoints. It is implemented on virtqueue #1. Whenever the host needs to
signal a fault, it fills one of the buffers offered by the guest and
interrupts it.
Signed-off-by: Jean-Philippe Brucker
---
drivers/iommu/virtio
virtio-iommu, because MSIs bypass it.
Signed-off-by: Jean-Philippe Brucker
---
drivers/iommu/virtio-iommu.c | 147 --
include/uapi/linux/virtio_iommu.h | 39
2 files changed, 180 insertions(+), 6 deletions(-)
diff --git a/drivers/iommu/virtio-iommu.c b
corresponding virtio requests. Mappings are kept in an interval tree
instead of page tables.
Signed-off-by: Jean-Philippe Brucker
---
MAINTAINERS | 7 +
drivers/iommu/Kconfig | 11 +
drivers/iommu/Makefile| 1 +
drivers/iommu/virtio-iommu.c | 938
For PCI devices that have an OF node, set the fwnode as well. This way
drivers that rely on fwnode don't need the special case described by
commit f94277af03ea ("of/platform: Initialise dev->fwnode appropriately").
Signed-off-by: Jean-Philippe Brucker
---
drivers/pci/of.c |
error out later, when attempting to find an MSI domain for the
device.
Signed-off-by: Jean-Philippe Brucker
---
drivers/pci/of.c | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/drivers/pci/of.c b/drivers/pci/of.c
index 1836b8ddf292..2f5015bdb256 100644
--- a/drivers/pci
rwise, the virtio-mmio device may perform DMA through an IOMMU, which
requires an "iommus" property. Describe these requirements in the
device-tree bindings documentation.
Signed-off-by: Jean-Philippe Brucker
---
.../devicetree/bindings/virtio/mmio.txt | 30 +++
des.
Signed-off-by: Jean-Philippe Brucker
---
.../devicetree/bindings/virtio/iommu.txt | 66 +++
1 file changed, 66 insertions(+)
create mode 100644 Documentation/devicetree/bindings/virtio/iommu.txt
diff --git a/Documentation/devicetree/bindings/virtio/iommu.txt
b/Document
.org/linux-jpb.git virtio-iommu/v0.8
git://linux-arm.org/kvmtool-jpb.git virtio-iommu/v0.8
Jean-Philippe Brucker (7):
dt-bindings: virtio-mmio: Add IOMMU description
dt-bindings: virtio: Add virtio-pci-iommu node
PCI: OF: allow endpoints to bypass the iommu
PCI: OF: Initialize dev->fwnod
On 26/09/2018 23:35, Jacob Pan wrote:
> On Thu, 20 Sep 2018 18:00:39 +0100
> Jean-Philippe Brucker wrote:
>
>> +
>> +static int io_mm_attach(struct iommu_domain *domain, struct device
>> *dev,
>> +struct io_mm *io_mm, void *drvdata)
&g
On 27/09/2018 21:37, Jacob Pan wrote:
> On Thu, 20 Sep 2018 18:00:43 +0100
> Jean-Philippe Brucker wrote:
>
>> +/*
>> + * When removing a PASID, the device driver tells the device
>> to stop
>> + * using it, and flush any pending fau
On 26/09/2018 19:01, Jacob Pan wrote:
> On Mon, 24 Sep 2018 13:07:47 +0100
> Jean-Philippe Brucker wrote:
>
>> On 23/09/2018 04:05, Lu Baolu wrote:
>> > Hi,
>> >
>> > On 09/21/2018 01:00 AM, Jean-Philippe Brucker wrote:
>> >> Add
On 27/09/2018 04:22, Liu, Yi L wrote:
>> For the "classic" vfio-pci case, "SVA in guest" still means giving the
>> guest control over the whole PASID table.
>
> No, if giving guest control over the whole PASID table, it means guest may
> have
> its own PASID namespace. right? And for vfio-mdev ca
On 26/09/2018 13:45, Joerg Roedel wrote:
> On Wed, Sep 26, 2018 at 11:20:34AM +0100, Jean-Philippe Brucker wrote:
>> Yes, at the moment it's difficult to guess what device drivers will
>> want, but I can imagine some driver offering SVA to userspace, while
>> keeping a fe
On 26/09/2018 00:33, Lu Baolu wrote:
> Hi Joerg,
>
> On 09/25/2018 09:26 PM, Joerg Roedel wrote:
>> On Tue, Sep 25, 2018 at 11:15:40AM +0800, Lu Baolu wrote:
>>> This might be problematic for vt-d (and other possible arch's which use
>>> PASID other than SVA). When vt-d iommu works in scalable mod
On 25/09/2018 23:46, Jacob Pan wrote:
> On Tue, 25 Sep 2018 15:16:47 +0200
> Joerg Roedel wrote:
>
>> On Sun, Sep 23, 2018 at 10:39:25AM +0800, Lu Baolu wrote:
>> > > +int iommu_sva_init_device(struct device *dev, unsigned long
>> > > features,
>> > > + unsigned int min_pasid, unsi
On 25/09/2018 23:17, Jacob Pan wrote:
> On Tue, 25 Sep 2018 15:58:41 +0100
> Jean-Philippe Brucker wrote:
>
>> Hi Jacob,
>>
>> Just two minor things below, that I noticed while using fault handlers
>> for SVA. From my perspective the series is fine otherwise
On 19/09/2018 00:26, Tian, Kevin wrote:
>> If the core actually calls it, we can implement detach_dev :) The
>> problem is that the core never calls detach_dev when default_domain is
>> present (affects any IOMMU driver that relies on default_domain,
>> including AMD), and even in case 4) the defau
Hi Jacob,
Just two minor things below, that I noticed while using fault handlers
for SVA. From my perspective the series is fine otherwise
On 11/05/2018 21:54, Jacob Pan wrote:
> +int iommu_unregister_device_fault_handler(struct device *dev)
> +{
> + struct iommu_param *param = dev->iommu_p
On 25/09/2018 04:15, Lu Baolu wrote:
>> + /* If an io_mm already exists, use it */
>> + spin_lock(&iommu_sva_lock);
>> + idr_for_each_entry(&iommu_pasid_idr, io_mm, i) {
>
> This might be problematic for vt-d (and other possible arch's which use
> PASID other than SVA). When vt-d iommu
On 23/09/2018 03:39, Lu Baolu wrote:
>> +int iommu_sva_init_device(struct device *dev, unsigned long features,
>> + unsigned int min_pasid, unsigned int max_pasid)
>> +{
>> + int ret;
>> + struct iommu_sva_param *param;
>> + struct iommu_domain *domain = iommu_get_dom
On 23/09/2018 04:05, Lu Baolu wrote:
> Hi,
>
> On 09/21/2018 01:00 AM, Jean-Philippe Brucker wrote:
>> Add bind() and unbind() operations to the IOMMU API. Bind() returns a
>> PASID that drivers can program in hardware, to let their devices access an
>> mm. This patch
When a recoverable page fault is handled by the fault workqueue, find the
associated mm and call handle_mm_fault.
Signed-off-by: Jean-Philippe Brucker
---
drivers/iommu/io-pgfault.c | 86 +-
1 file changed, 84 insertions(+), 2 deletions(-)
diff --git a
is NULL, in which case it should allocate io_pgtables instead of
binding to an mm.
Signed-off-by: Jordan Crouse
Signed-off-by: Jean-Philippe Brucker
---
Sadly this probably won't be the final thing. The API in this patch is
used like this:
iommu_sva_alloc_pasid(dev, &io_mm)
river
aborts iommu_sva_init_device().
The fault queue must be flushed before any io_mm is freed, to make sure
that its PASID isn't used in any fault queue, and can be reallocated.
Add iopf_queue_flush() calls in a few strategic locations.
Signed-off-by: Jean-Philippe Brucker
---
drivers/iommu/i
-by: Jean-Philippe Brucker
---
v2->v3: Add MMU_INVALIDATE_DOES_NOT_BLOCK flag to MMU notifier
In v2 Christian pointed out that letting mm_exit() linger for too long
(some devices could need minutes to flush a PASID context) might force
the OOM killer to kill additional tasks, for example if
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-Philippe Brucker
---
v2->v3:
* queue_flush
The fault handler will need to find an mm given its PASID. This is the
reason we have an IDR for storing address spaces, so hook it up.
Signed-off-by: Jean-Philippe Brucker
---
drivers/iommu/iommu-sva.c | 26 ++
include/linux/iommu.h | 7 +++
2 files changed, 33
When an mm exits, devices that were bound to it must stop performing DMA
on its PASID. Let device drivers register a callback to be notified on mm
exit. Add the callback to the sva_param structure attached to struct
device.
Signed-off-by: Jean-Philippe Brucker
---
drivers/iommu/iommu-sva.c | 10
c() for the moment.
Signed-off-by: Jean-Philippe Brucker
---
v2->v3: use sva_lock, comment updates
---
drivers/iommu/iommu-sva.c | 397 +-
drivers/iommu/iommu.c | 1 +
include/linux/iommu.h | 29 +++
3 files changed, 424 insertions(+), 3 deletions(-
Add bind() and unbind() operations to the IOMMU API. Bind() returns a
PASID that drivers can program in hardware, to let their devices access an
mm. This patch only adds skeletons for the device driver API, most of the
implementation is still missing.
Signed-off-by: Jean-Philippe Brucker
e added in a later patch using a new
feature bit (IOMMU_SVA_FEAT_IOPF). With the current API users must pin
down all shared mappings.
Signed-off-by: Jean-Philippe Brucker
---
v2->v3:
* Add sva_lock to serialize init/bind/unbind/shutdown
* Rename functions for consistency with the rest of the API
2.html
[3]
https://lwn.net/ml/linux-kernel/20180830040922.30426-1-baolu...@linux.intel.com/
[4]
https://lwn.net/ml/linux-kernel/1526072055-86990-1-git-send-email-jacob.jun.pan%40linux.intel.com/
Jean-Philippe Brucker (10):
iommu: Introduce Shared Virtual Addressing API
iommu/sva: Bind process add
On 15/09/2018 03:36, Tian, Kevin wrote:
>> 4) Userspace opens another mdev.
>> -> iommu.c calls domain->ops->attach_dev(domain2, dev)
>
> another mdev in same VFIO container or different? I assume the
> latter since you mentioned a new domain2.
I was thinking a different VFIO container actually.
On 14/09/2018 22:04, Jacob Pan wrote:
>> This example only needs to modify first-level translation, and works
>> with SMMUv3. The kernel here could be the host, in which case
>> second-level translation is disabled in the SMMU, or it could be the
>> guest, in which case second-level mappings are cr
On 13/09/2018 01:35, Tian, Kevin wrote:
>>> Let's consider it from the API point of view.
>>>
>>> We have iommu_a(de)ttach_device() APIs to attach or detach a domain
>>> to/from a device. We should avoid applying a limitation of "these are
>>> only for single domain case, for multiple domains, use
>> This example only needs to modify first-level translation, and works
>> with SMMUv3. The kernel here could be the host, in which case
>> second-level translation is disabled in the SMMU, or it could be the
>> guest, in which case second-level mappings are created by QEMU and
>> first-level trans
On 13/09/2018 17:55, Raj, Ashok wrote:
>> For Arm SMMU we're more interested in the PASID-granular case than the
>> RID-granular one. It doesn't necessarily require vt-d rev3 scalable
>> mode, the following example can be implemented with an SMMUv3, since it
>> only needs PASID-granular first-level
On 13/09/2018 01:19, Tian, Kevin wrote:
>>> This is proposed for architectures which support finer granularity
>>> second level translation with no impact on architectures which only
>>> support Source ID or the similar granularity.
>>
>> Just to be clear, in this paragraph you're only referring to
On 12/09/2018 06:02, Lu Baolu wrote:
> Hi,
>
> On 09/11/2018 12:23 AM, Jean-Philippe Brucker wrote:
>> On 30/08/2018 05:09, Lu Baolu wrote:
>>> +static int vfio_detach_aux_domain(struct device *dev, void *data)
>>> +{
>>&
On 12/09/2018 03:42, Lu Baolu wrote:
> Hi,
>
> On 09/11/2018 12:22 AM, Jean-Philippe Brucker wrote:
>> Hi,
>>
>> On 30/08/2018 05:09, Lu Baolu wrote:
>>> Below APIs are introduced in the IOMMU glue for device drivers to use
>>> the finer gra
On 08/09/2018 08:29, Christian König wrote:
> Yes, exactly. I just need a PASID which is never used by the OS for a
> process and we can easily give that back when the last FD reference is
> closed.
Alright, iommu-sva can get its PASID from this external allocator as
well, as long as it has an i
On 30/08/2018 05:09, Lu Baolu wrote:
> +static int vfio_detach_aux_domain(struct device *dev, void *data)
> +{
> + struct iommu_domain *domain = data;
> +
> + vfio_mdev_set_aux_domain(dev, NULL);
> + iommu_detach_device(domain, dev->parent);
I think that's only going to work for vt-d,
Hi,
On 30/08/2018 05:09, Lu Baolu wrote:
> Below APIs are introduced in the IOMMU glue for device drivers to use
> the finer granularity translation.
>
> * iommu_capable(IOMMU_CAP_AUX_DOMAIN)
> - Represents the ability for supporting multiple domains per device
> (a.k.a. finer granularity t
On 07/09/2018 17:53, Jerome Glisse wrote:
> So there is no reasons to do that under VFIO. Especialy as in your example
> it is not a real user space device driver, the userspace portion only knows
> about writting command into command buffer AFAICT.
>
> VFIO is for real userspace driver where inte
On 07/09/2018 09:55, Christian König wrote:
> I will take this as an opportunity to summarize some of the requirements
> we have for PASID management from the amdgpu driver point of view:
That's incredibly useful, thanks :)
> 1. We need to be able to allocate PASID between 1 and some maximum. Ze
On 07/09/2018 08:11, Auger Eric wrote:
>>> On 09/06/2018 02:42 PM, Jean-Philippe Brucker wrote:
>>>> On 06/09/2018 10:25, Auger Eric wrote:
>>>>>> +mutex_lock(&fparam->lock);
>>>>>> +list_add_tail(&
On 05/09/2018 19:18, Jacob Pan wrote:
> On Wed, 5 Sep 2018 14:14:12 +0200
> Auger Eric wrote:
>
>>> + *
>>> + * On Arm and AMD IOMMUs, entry 0 of the PASID table can be used
>>> to hold
>>> + * non-PASID translations. In this case PASID 0 is reserved and
>>> entry 0 points
>>> + * to the io_pgtab
On 06/09/2018 14:14, Auger Eric wrote:
> Hi Jean-Philippe,
>
> On 09/06/2018 02:42 PM, Jean-Philippe Brucker wrote:
>> On 06/09/2018 10:25, Auger Eric wrote:
>>>> + mutex_lock(&fparam->lock);
>>>> + list_add_tail(&evt_pending
On 06/09/2018 12:12, Christian König wrote:
> Am 06.09.2018 um 13:09 schrieb Jean-Philippe Brucker:
>> Hi Eric,
>>
>> Thanks for reviewing
>>
>> On 05/09/2018 12:29, Auger Eric wrote:
>>>> +int iommu_sva_device_init(struct device *dev, unsigned lo
1101 - 1200 of 1703 matches
Mail list logo
