On Wed, 2019-10-23 at 17:55 +0100, Will Deacon wrote:
> On Wed, Oct 16, 2019 at 11:33:08AM +0800, Yong Wu wrote:
> > Use the iommu_gather mechanism to achieve the tlb range flush.
> > Gather the iova range in the "tlb_add_page", then flush the merged iova
> > range in iotlb_sync.
> >
> >
On Wed, 2019-10-23 at 17:52 +0100, Will Deacon wrote:
> On Wed, Oct 16, 2019 at 11:33:07AM +0800, Yong Wu wrote:
> > The commit 4d689b619445 ("iommu/io-pgtable-arm-v7s: Convert to IOMMU API
> > TLB sync") help move the tlb_sync of unmap from v7s into the iommu
> > framework. It helps add a new
On 24.10.2019 05:01, h...@lst.de wrote:
> On Wed, Oct 23, 2019 at 11:53:41AM +, Laurentiu Tudor wrote:
>> We had an internal discussion over these points you are raising and
>> Madalin (cc-ed) came up with another idea: instead of adding this prone
>> to misuse api how about experimenting
On Thu, Oct 24, 2019 at 11:51:51AM +0100, Will Deacon wrote:
> Hi all,
>
> In commit 90ec7a76cc4b ("iommu/io-pgtable-arm: Add support to use system
> cache") we added support for IOMMU_QCOM_SYS_CACHE which was merged into 5.3.
> This allows non-coherent devices to request an outer cacheable
Hi Vlad,
On 10/24/19 2:43 PM, Vladimir Murzin wrote:
On 10/17/19 10:46 AM, Vladimir Murzin wrote:
I'm wondering if I've missed something with diff bellow (it was a long time ago
when I touched DMA)?
Any comments on that? I can only build test it, so lack of testing stopping me
from sending
Hi Alex,
On 10/24/19 4:20 PM, Alexandre Torgue wrote:
> Hi Vlad,
>
> On 10/24/19 2:43 PM, Vladimir Murzin wrote:
>> On 10/17/19 10:46 AM, Vladimir Murzin wrote:
>>> I'm wondering if I've missed something with diff bellow (it was a long time
>>> ago when I touched DMA)?
>>
>> Any comments on
On Fri, Oct 4, 2019 at 4:27 PM Robin Murphy wrote:
>
> On 2019-10-04 9:37 pm, Tim Harvey wrote:
> > On Fri, Oct 4, 2019 at 11:34 AM Robin Murphy wrote:
> >>
> >> On 04/10/2019 18:13, Tim Harvey wrote:
> >> [...]
> > No difference... still need 'arm-smmu.disable_bypass=n' to boot. Are
> >
From: Laurentiu Tudor
This series introduces a few new dma unmap and sync api variants that,
on top of what the originals do, return the physical address
corresponding to the input dma address. In order to do that a new dma
map op is added, .get_phys_addr that takes the input dma address and
On 2019-10-24 16:51, Will Deacon wrote:
On Thu, Oct 24, 2019 at 04:41:04PM +0530, Sai Prakash Ranjan wrote:
On 2019-10-24 16:21, Will Deacon wrote:
> In commit 90ec7a76cc4b ("iommu/io-pgtable-arm: Add support to use system
> cache") we added support for IOMMU_QCOM_SYS_CACHE which was merged
From: Laurentiu Tudor
Convert this driver to usage of the newly introduced dma unmap and
sync DMA APIs. This will get rid of the unsupported direct usage of
iommu_iova_to_phys() API.
Signed-off-by: Laurentiu Tudor
---
.../net/ethernet/freescale/dpaa2/dpaa2-eth.c | 40 +++
From: Laurentiu Tudor
Add an implementation of the newly introduced dma map op in the
generic DMA IOMMU generic glue layer and wire it up.
Signed-off-by: Laurentiu Tudor
---
drivers/iommu/dma-iommu.c | 16
1 file changed, 16 insertions(+)
diff --git
From: Laurentiu Tudor
Introduce a few new dma unmap and sync variants that, on top of the
original variants, return the virtual address corresponding to the
input dma address.
In order to implement this a new dma map op is added and used:
void *get_virt_addr(dev, dma_handle);
It does the
From: Laurentiu Tudor
This series introduces a few new dma unmap and sync api variants that,
on top of what the originals do, return the virtual address
corresponding to the input dma address. In order to do that a new dma
map op is added, .get_virt_addr that takes the input dma address and
On Thu, Oct 03, 2019 at 11:33:52AM -0600, Jordan Crouse wrote:
> On Wed, Aug 21, 2019 at 01:56:20PM +0100, Robin Murphy wrote:
> > On 21/08/2019 13:11, Will Deacon wrote:
> > >On Tue, Aug 20, 2019 at 07:41:52PM +0100, Robin Murphy wrote:
> > >>On 20/08/2019 17:07, Will Deacon wrote:
> > >>>On Tue,
Hi all,
In commit 90ec7a76cc4b ("iommu/io-pgtable-arm: Add support to use system
cache") we added support for IOMMU_QCOM_SYS_CACHE which was merged into 5.3.
This allows non-coherent devices to request an outer cacheable memory
type except that nobody actually does this in mainline. I
Hi Will,
On 2019-10-24 16:21, Will Deacon wrote:
Hi all,
In commit 90ec7a76cc4b ("iommu/io-pgtable-arm: Add support to use
system
cache") we added support for IOMMU_QCOM_SYS_CACHE which was merged into
5.3.
This allows non-coherent devices to request an outer cacheable memory
type
On 2019-10-24 11:51 am, Will Deacon wrote:
On Thu, Oct 03, 2019 at 11:33:52AM -0600, Jordan Crouse wrote:
On Wed, Aug 21, 2019 at 01:56:20PM +0100, Robin Murphy wrote:
On 21/08/2019 13:11, Will Deacon wrote:
On Tue, Aug 20, 2019 at 07:41:52PM +0100, Robin Murphy wrote:
On 20/08/2019 17:07,
From: Laurentiu Tudor
Convert this driver to usage of the newly introduced dma unmap and
sync DMA APIs. This will get rid of the unsupported direct usage of
iommu_iova_to_phys() API.
Signed-off-by: Laurentiu Tudor
---
.../net/ethernet/freescale/dpaa2/dpaa2-eth.c | 43 ---
From: Laurentiu Tudor
Introduce a few new dma unmap and sync variants that, on top of the
original variants, return the physical address corresponding to the
input dma address.
In order to implement this a new dma map op is added and used:
phys_addr_t get_phys_addr(dev, dma_handle);
It does
From: Laurentiu Tudor
Add an implementation of the newly introduced dma map op in the
generic DMA IOMMU generic glue layer and wire it up.
Signed-off-by: Laurentiu Tudor
---
drivers/iommu/dma-iommu.c | 12
1 file changed, 12 insertions(+)
diff --git a/drivers/iommu/dma-iommu.c
On Thu, Oct 24, 2019 at 04:41:04PM +0530, Sai Prakash Ranjan wrote:
> On 2019-10-24 16:21, Will Deacon wrote:
> > In commit 90ec7a76cc4b ("iommu/io-pgtable-arm: Add support to use system
> > cache") we added support for IOMMU_QCOM_SYS_CACHE which was merged into
> > 5.3.
> > This allows
On 10/17/19 10:46 AM, Vladimir Murzin wrote:
> I'm wondering if I've missed something with diff bellow (it was a long time
> ago when I touched DMA)?
Any comments on that? I can only build test it, so lack of testing stopping me
from sending it as a
proper patch :(
>
> diff --git
From: Liu Yi L
When the guest "owns" the stage 1 translation structures, the host
IOMMU driver has no knowledge of caching structure updates unless
the guest invalidation requests are trapped and passed down to the
host.
This patch adds the VFIO_IOMMU_CACHE_INVALIDATE ioctl with aims
at
This patch adds vfio support to bind guest translation structure
to host iommu. VFIO exposes iommu programming capability to user-
space. Guest is a user-space application in host under KVM solution.
For SVA usage in Virtual Machine, guest owns GVA->GPA translation
structure. And this part should
The PLX PEX NTB forwards DMA transactions using Requester ID's that don't exist
as
PCI devices. The devfn for a transaction is used as an index into a lookup table
storing the origin of a transaction on the other side of the bridge.
This patch aliases all possible devfn's to the NTB device so
This patch adds VFIO_IOMMU_PASID_REQUEST ioctl which aims
to passdown PASID allocation/free request from the virtual
iommu. This is required to get PASID managed in system-wide.
Cc: Kevin Tian
Signed-off-by: Liu Yi L
Signed-off-by: Yi Sun
Signed-off-by: Jacob Pan
---
Shared virtual address (SVA), a.k.a, Shared virtual memory (SVM) on Intel
platforms allow address space sharing between device DMA and applications.
SVA can reduce programming complexity and enhance security.
This series is intended to expose SVA capability to VMs. i.e. shared guest
application
On 24.10.2019 14:04, Robin Murphy wrote:
> On 2019-10-24 8:49 am, Laurentiu Tudor wrote:
>>
>>
>> On 24.10.2019 05:01, h...@lst.de wrote:
>>> On Wed, Oct 23, 2019 at 11:53:41AM +, Laurentiu Tudor wrote:
We had an internal discussion over these points you are raising and
Madalin
On Thu, Oct 24, 2019 at 12:23:46PM +0100, Robin Murphy wrote:
> On 2019-10-24 11:51 am, Will Deacon wrote:
> > On Thu, Oct 03, 2019 at 11:33:52AM -0600, Jordan Crouse wrote:
> > > On Wed, Aug 21, 2019 at 01:56:20PM +0100, Robin Murphy wrote:
> > > > On 21/08/2019 13:11, Will Deacon wrote:
> > > >
On 2019-10-24 8:49 am, Laurentiu Tudor wrote:
On 24.10.2019 05:01, h...@lst.de wrote:
On Wed, Oct 23, 2019 at 11:53:41AM +, Laurentiu Tudor wrote:
We had an internal discussion over these points you are raising and
Madalin (cc-ed) came up with another idea: instead of adding this prone
When VT-d driver runs in the guest, PASID allocation must be
performed via virtual command interface. This patch registers a
custom IOASID allocator which takes precedence over the default
XArray based allocator. The resulting IOASID allocation will always
come from the host. This ensures that
From: Lu Baolu
Enabling IOMMU in a guest requires communication with the host
driver for certain aspects. Use of PASID ID to enable Shared Virtual
Addressing (SVA) requires managing PASID's in the host. VT-d 3.0 spec
provides a Virtual Command Register (VCMD) to facilitate this.
Writes to this
Shared virtual address (SVA), a.k.a, Shared virtual memory (SVM) on Intel
platforms allow address space sharing between device DMA and applications.
SVA can reduce programming complexity and enhance security.
This series is intended to enable SVA virtualization, i.e. enable use of SVA
within a
Virtual command registers are used in the guest only, to prevent
vmexit cost, we cache the capability and store it during initialization.
Signed-off-by: Jacob Pan
---
drivers/iommu/dmar.c| 1 +
include/linux/intel-iommu.h | 4
2 files changed, 5 insertions(+)
diff --git
When Shared Virtual Address (SVA) is enabled for a guest OS via
vIOMMU, we need to provide invalidation support at IOMMU API and driver
level. This patch adds Intel VT-d specific function to implement
iommu passdown invalidate API for shared virtual address.
The use case is for supporting caching
Move domain helper to header to be used by SVA code.
Signed-off-by: Jacob Pan
Reviewed-by: Eric Auger
---
drivers/iommu/intel-iommu.c | 6 --
include/linux/intel-iommu.h | 6 ++
2 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/iommu/intel-iommu.c
Use combined macros for_each_svm_dev() to simplify SVM device iteration
and error checking.
Suggested-by: Andy Shevchenko
Signed-off-by: Jacob Pan
Reviewed-by: Eric Auger
---
drivers/iommu/intel-svm.c | 89 ++-
1 file changed, 42 insertions(+), 47
When supporting guest SVA with emulated IOMMU, the guest PASID
table is shadowed in VMM. Updates to guest vIOMMU PASID table
will result in PASID cache flush which will be passed down to
the host as bind guest PASID calls.
For the SL page tables, it will be harvested from device's
default domain
When Shared Virtual Memory is exposed to a guest via vIOMMU, scalable
IOTLB invalidation may be passed down from outside IOMMU subsystems.
This patch adds invalidation functions that can be used for additional
translation cache types.
Signed-off-by: Jacob Pan
---
drivers/iommu/dmar.c|
Make use of generic IOASID code to manage PASID allocation,
free, and lookup. Replace Intel specific code.
Signed-off-by: Jacob Pan
---
drivers/iommu/intel-iommu.c | 12 ++--
drivers/iommu/intel-pasid.c | 36
drivers/iommu/intel-svm.c | 39
After each setup for PASID entry, related translation caches must be flushed.
We can combine duplicated code into one function which is less error prone.
Signed-off-by: Jacob Pan
---
drivers/iommu/intel-pasid.c | 48 +
1 file changed, 18
Nested translation mode is supported in VT-d 3.0 Spec.CH 3.8.
With PASID granular translation type set to 0x11b, translation
result from the first level(FL) also subject to a second level(SL)
page table translation. This mode is used for SVA virtualization,
where FL performs guest virtual to guest
Hi,
On 10/24/19 1:55 AM, Jacob Pan wrote:
On Wed, 23 Oct 2019 09:53:04 +0800
Lu Baolu wrote:
Hi Ashok,
Thanks for reviewing the patch.
On 10/23/19 8:45 AM, Raj, Ashok wrote:
On Tue, Oct 22, 2019 at 04:53:14PM -0700, Jacob Pan wrote:
From: Lu Baolu
If Intel IOMMU runs in caching mode,
Hi,
On 10/25/19 3:54 AM, Jacob Pan wrote:
Virtual command registers are used in the guest only, to prevent
vmexit cost, we cache the capability and store it during initialization.
Signed-off-by: Jacob Pan
This patch looks good to me.
Reviewed-by: Lu Baolu
Best regards,
baolu
---
Hi Jacob,
On 10/25/19 3:54 AM, Jacob Pan wrote:
When VT-d driver runs in the guest, PASID allocation must be
performed via virtual command interface. This patch registers a
custom IOASID allocator which takes precedence over the default
XArray based allocator. The resulting IOASID allocation
Hi,
On 10/24/19 5:11 AM, Jacob Pan wrote:
On Wed, 23 Oct 2019 10:55:23 -0700
Jacob Pan wrote:
Do you have to check this everytime? every dmar_readq is going to
trap to the other side ...
Yes. We don't need to check it every time. Check once and save the
result during boot is enough.
How
Hi,
On 10/24/19 7:01 AM, Jacob Pan wrote:
On Wed, 23 Oct 2019 10:21:51 +0800
Lu Baolu wrote:
+#ifdef CONFIG_INTEL_IOMMU_SVM
Maybe move them to intel-svm.c instead? that's where the bulk
of the svm support is?
I think this is a generic PASID allocator for guest IOMMU although
vSVA is
Hi,
On 10/25/19 3:54 AM, Jacob Pan wrote:
Make use of generic IOASID code to manage PASID allocation,
free, and lookup. Replace Intel specific code.
Signed-off-by: Jacob Pan
---
drivers/iommu/intel-iommu.c | 12 ++--
drivers/iommu/intel-pasid.c | 36
HI,
On 10/25/19 3:54 AM, Jacob Pan wrote:
Move domain helper to header to be used by SVA code.
Signed-off-by: Jacob Pan
Reviewed-by: Eric Auger
This patch looks good to me.
Reviewed-by: Lu Baolu
Best regards,
baolu
---
drivers/iommu/intel-iommu.c | 6 --
Hi Baolu,
Thanks for the review. please see my comments inline.
On Fri, 25 Oct 2019 10:30:48 +0800
Lu Baolu wrote:
> Hi Jacob,
>
> On 10/25/19 3:54 AM, Jacob Pan wrote:
> > When VT-d driver runs in the guest, PASID allocation must be
> > performed via virtual command interface. This patch
Hi,
On 10/25/19 3:54 AM, Jacob Pan wrote:
After each setup for PASID entry, related translation caches must be flushed.
We can combine duplicated code into one function which is less error prone.
Signed-off-by: Jacob Pan
This patch looks good to me.
Reviewed-by: Lu Baolu
Best regards,
51 matches
Mail list logo
