On Tue, 22 Oct 2019 17:58:59 -0700
"Raj, Ashok" wrote:
> On Tue, Oct 22, 2019 at 04:53:16PM -0700, 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
> > ---
> >
On Tue, 22 Oct 2019 17:51:29 -0700
"Raj, Ashok" wrote:
> On Tue, Oct 22, 2019 at 04:53:15PM -0700, 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
Hi,
On 10/23/19 8:51 AM, Raj, Ashok wrote:
On Tue, Oct 22, 2019 at 04:53:15PM -0700, 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
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, a.k.a. virtual IOMMU, the
IOMMU driver should rely on the emulation software to allocate
and free
On Tue, Oct 22, 2019 at 04:53:16PM -0700, 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
On Tue, Oct 22, 2019 at 04:53:15PM -0700, 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
On Tue, Oct 22, 2019 at 04:53:14PM -0700, Jacob Pan wrote:
> From: Lu Baolu
>
> If Intel IOMMU runs in caching mode, a.k.a. virtual IOMMU, the
> IOMMU driver should rely on the emulation software to allocate
> and free PASID IDs. The Intel vt-d spec revision 3.0 defines a
> register set to
Hi Jacob
On Tue, Oct 22, 2019 at 04:53:13PM -0700, Jacob Pan wrote:
> 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
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|
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
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
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
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. shared guest
application
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 | 85 +++
1 file changed, 41 insertions(+), 44
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
From: Lu Baolu
If Intel IOMMU runs in caching mode, a.k.a. virtual IOMMU, the
IOMMU driver should rely on the emulation software to allocate
and free PASID IDs. The Intel vt-d spec revision 3.0 defines a
register set to support this. This includes a capability register,
a virtual command
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
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 | 37
Hi Robin,
>>Apologies for crossed wires, but I had a series getting rid of
>>arm_smmu_flush_ops which was also meant to end up making things a bit easier
>>for you:
I was looking to rebase on top of your changes first. Then I read Will's reply
that said your work is queued for 5.5.
Let me
Non-Transparent Bridge (NTB) devices (among others) may have many DMA
aliases seeing the hardware will send requests with different device ids
depending on their origin across the bridged hardware.
See commit ad281ecf1c7d ("PCI: Add DMA alias quirk for Microsemi Switchtec
NTB") for more
Non-Transparent Bridge (NTB) devices (among others) may have many DMA
aliases seeing the hardware will send requests with different device ids
depending on their origin across the bridged hardware.
See commit ad281ecf1c7d ("PCI: Add DMA alias quirk for Microsemi
Switchtec NTB") for more
Hi,
Please find the following patches which help support
Non-Transparent-Bridge (NTB) devices on AMD platforms with the IOMMU
enabled.
These patches add support for multiple PCI aliases. NTB
hardware will normally send TLPs from a range of requestor IDs to
facilitate routing the responses back
On 19/10/2019 00:31, Krishna Reddy wrote:
Add binding for NVIDIA's Tegra194 Soc SMMU that is based
on ARM MMU-500.
Signed-off-by: Krishna Reddy
---
Documentation/devicetree/bindings/iommu/arm,smmu.txt | 4
Rob (+cc) is in the process of converting the SMMU bindings to schema,
so we
Hi Krishna,
On 19/10/2019 00:31, Krishna Reddy wrote:
Changes in v3:
Rebased on top of
https://git.kernel.org/pub/scm/linux/kernel/git/joro/iommu.git/ next.
Resolved compile error seen with tegra194.dtsi changes after rebase.
Apologies for crossed wires, but I had a series getting rid of
On Tue, Oct 22, 2019 at 11:54 AM Robin Murphy wrote:
>
> On 14/10/2019 20:12, Rob Herring wrote:
> > Convert the Arm SMMv3 binding to the DT schema format.
> >
> > Cc: Joerg Roedel
> > Cc: Mark Rutland
> > Cc: Will Deacon
> > Cc: Robin Murphy
> > Cc: iommu@lists.linux-foundation.org
> >
On 14/10/2019 20:12, Rob Herring wrote:
Convert the Arm SMMv3 binding to the DT schema format.
Cc: Joerg Roedel
Cc: Mark Rutland
Cc: Will Deacon
Cc: Robin Murphy
Cc: iommu@lists.linux-foundation.org
Signed-off-by: Rob Herring
---
v2:
- Refine interrupt definition based on Robin's comments
On 20/10/2019 06:03, Shyam Saini wrote:
These parameters are only referenced by __init routine calls during early
boot so they should be marked as __initdata and __initconst accordingly.
Reviewed-by: Robin Murphy
Cc: Christoph Hellwig
Cc: Marek Szyprowski
Cc: Robin Murphy
Cc: Matthew
On 22.10.2019 16:25, Robin Murphy wrote:
> On 22/10/2019 13:55, Laurentiu Tudor wrote:
>> From: Laurentiu Tudor
>>
>> Introduce a new dma map op called dma_addr_to_phys_addr() that converts
>> a dma address to the physical address backing it up and add wrapper for
>> it.
>
> I'd really love it
On 22/10/2019 13:55, Laurentiu Tudor wrote:
From: Laurentiu Tudor
Introduce a new dma map op called dma_addr_to_phys_addr() that converts
a dma address to the physical address backing it up and add wrapper for
it.
I'd really love it if there was a name which could encapsulate that this
is
From: Laurentiu Tudor
Introduce a new dma map op called dma_addr_to_phys_addr() that converts
a dma address to the physical address backing it up and add wrapper for
it.
Signed-off-by: Laurentiu Tudor
---
include/linux/dma-mapping.h | 21 +
1 file changed, 21 insertions(+)
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
From: Laurentiu Tudor
This series introduces a new dma api called dma_addr_to_phys_addr()
that converts a dma address to the corresponding physical address.
It consists in a new dma map op and the wrapper api, both added
in the first patch. The second patch adds an implementation in the
iommu
From: Laurentiu Tudor
Convert this driver to usage of the newly introduced
dma_addr_to_phys_addr() DMA API. 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 | 21 +++
On Hyper-V, Generation 1 VMs can directly use VM's physical memory for
their framebuffers. This can improve the efficiency of framebuffer and
overall performence for VM. The physical memory assigned to framebuffer
must be contiguous. We use CMA allocator to get contiguouse physicial
memory when
35 matches
Mail list logo
