Hi,
On 1/21/20 6:14 PM, John Garry wrote:
On 21/01/2020 00:43, Lu Baolu wrote:
An IOMMU group represents the smallest set of devices that are
considered
to be isolated. All devices belonging to an IOMMU group share a default
domain for DMA APIs. There are two types of default domain:
Hi Robin,
On 1/21/20 8:45 PM, Robin Murphy wrote:
On 19/01/2020 6:29 am, Lu Baolu wrote:
Hi Joerg,
On 1/17/20 6:21 PM, Joerg Roedel wrote:
On Wed, Jan 01, 2020 at 01:26:47PM +0800, Lu Baolu wrote:
This splits iommu group allocation from adding devices. This makes
it possible to determine
It is possible for archdata.iommu to be set to
DEFER_DEVICE_DOMAIN_INFO or DUMMY_DEVICE_DOMAIN_INFO so check for
those values before calling __dmar_remove_one_dev_info. Without a
check it can result in a null pointer dereference. This has been seen
while booting a kdump kernel on an HP dl380 gen9.
On Thu, Dec 19, 2019 at 08:52:45PM -0500, Konrad Rzeszutek Wilk wrote:
> On Mon, Dec 09, 2019 at 11:13:46PM +, Ashish Kalra wrote:
> > From: Ashish Kalra
> >
> > For SEV, all DMA to and from guest has to use shared
> > (un-encrypted) pages. SEV uses SWIOTLB to make this happen
> > without
On 1/22/20 8:34 AM, Jerry Snitselaar wrote:
It is possible for archdata.iommu to be set to
DEFER_DEVICE_DOMAIN_INFO or DUMMY_DEVICE_DOMAIN_INFO so check for
those values before calling __dmar_remove_one_dev_info. Without a
check it can result in a null pointer dereference. This has been seen
On 1/21/20 9:37 PM, Jon Derrick wrote:
This removes the sanity check required for VMD child devices. The new
pci_real_dma_dev() DMA alias mechanism places them in the same IOMMU
group as the VMD endpoint. Assignment of the group would require
assigning the VMD endpoint, where unbinding the VMD
On 1/21/20 9:37 PM, Jon Derrick wrote:
The PCI device may have a DMA requester on another bus, such as VMD
subdevices needing to use the VMD endpoint. This case requires the real
DMA device when mapping to IOMMU.
Signed-off-by: Jon Derrick
Acked-by: Lu Baolu
Thanks,
baolu
The PCI device may have a DMA requester on another bus, such as VMD
subdevices needing to use the VMD endpoint. This case requires the real
DMA device when mapping to IOMMU.
Signed-off-by: Jon Derrick
---
drivers/iommu/intel-iommu.c | 5 +
1 file changed, 5 insertions(+)
diff --git
From: Christoph Hellwig
Various helpers need the pci_sysdata just to dereference a single field
in it. Add a little helper that returns the properly typed sysdata
pointer to require a little less boilerplate code.
Signed-off-by: Christoph Hellwig
[jonathan.derrick: to_pci_sysdata const
Devices on the VMD domain use the VMD endpoint's requester ID and have
been relying on the VMD endpoint's DMA operations. The problem with this
was that VMD domain devices would use the VMD endpoint's attributes when
doing DMA and IOMMU mapping. We can be smarter about this by only using
the VMD
To be used by Intel-IOMMU code to find the correct domain.
CC: Christoph Hellwig
Signed-off-by: Jon Derrick
---
arch/x86/include/asm/pci.h | 4 ++--
drivers/pci/controller/vmd.c | 2 +-
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/x86/include/asm/pci.h
The current DMA alias implementation requires the aliased device be on
the same PCI bus as the requester ID. This introduces an arch-specific
mechanism to point to another PCI device when doing mapping and
PCI DMA alias search. The default case returns the actual device.
CC: Christoph Hellwig
This removes the sanity check required for VMD child devices. The new
pci_real_dma_dev() DMA alias mechanism places them in the same IOMMU
group as the VMD endpoint. Assignment of the group would require
assigning the VMD endpoint, where unbinding the VMD endpoint removes the
child device domain
From: Christoph Hellwig
There are no users of X86_DEV_DMA_OPS left, so remove the code.
Reviewed-by: Jon Derrick
Signed-off-by: Christoph Hellwig
---
arch/x86/Kconfig | 3 ---
arch/x86/include/asm/device.h | 10 --
arch/x86/pci/common.c | 38
v4 Set:
https://lore.kernel.org/linux-pci/20200120110220.gb17...@e121166-lin.cambridge.arm.com/T/#t
v3 Set:
https://lore.kernel.org/linux-iommu/20200113181742.ga27...@e121166-lin.cambridge.arm.com/T/#t
v2 Set:
On Tue, Jan 21, 2020 at 08:09:47PM +, Ashish Kalra wrote:
> On Thu, Dec 19, 2019 at 08:52:45PM -0500, Konrad Rzeszutek Wilk wrote:
> > On Mon, Dec 09, 2019 at 11:13:46PM +, Ashish Kalra wrote:
> > > From: Ashish Kalra
> > >
> > > For SEV, all DMA to and from guest has to use shared
> > >
On 18/12/2019 4:39 am, Cong Wang wrote:
If the magazine is empty, iova_magazine_free_pfns() should
be a nop, however it misses the case of mag->size==0. So we
should just call iova_magazine_empty().
This should reduce the contention on iovad->iova_rbtree_lock
a little bit, not much at all.
On 18/12/2019 4:39 am, Cong Wang wrote:
Both find_iova() and __free_iova() take iova_rbtree_lock,
there is no reason to take and release it twice inside
free_iova().
Fold them into one critical section by calling the unlock
versions instead.
Makes sense to me.
Reviewed-by: Robin Murphy
On 21/01/2020 00:43, Lu Baolu wrote:
An IOMMU group represents the smallest set of devices that are
considered
to be isolated. All devices belonging to an IOMMU group share a default
domain for DMA APIs. There are two types of default domain:
IOMMU_DOMAIN_DMA
and IOMMU_DOMAIN_IDENTITY. The
On 18/12/2019 4:39 am, Cong Wang wrote:
The IOVA cache algorithm implemented in IOMMU code does not
exactly match the original algorithm described in the paper
"Magazines and Vmem: Extending the Slab Allocator to Many
CPUs and Arbitrary Resources".
Particularly, it doesn't need to free the
On 19/01/2020 6:29 am, Lu Baolu wrote:
Hi Joerg,
On 1/17/20 6:21 PM, Joerg Roedel wrote:
On Wed, Jan 01, 2020 at 01:26:47PM +0800, Lu Baolu wrote:
This splits iommu group allocation from adding devices. This makes
it possible to determine the default domain type for each group as
all devices
[+cc linux-pci, thread at
https://lore.kernel.org/r/20200101052648.14295-1-baolu...@linux.intel.com]
On Wed, Jan 01, 2020 at 01:26:46PM +0800, Lu Baolu wrote:
> The new parameter takes a list of devices separated by a semicolon.
> Each device specified will have its iommu_passthrough bit in
On 16/12/2019 4:37 pm, Jordan Crouse wrote:
Add support to enable split pagetables (TTBR1) if the supporting driver
requests it via the DOMAIN_ATTR_SPLIT_TABLES flag. When enabled, the driver
will set up the TTBR0 and TTBR1 regions and program the default domain
pagetable on TTBR1.
After
Oh, one more thing...
On 16/12/2019 4:37 pm, Jordan Crouse wrote:
[...]
@@ -651,6 +659,7 @@ static int arm_smmu_init_domain_context(struct iommu_domain
*domain,
enum io_pgtable_fmt fmt;
struct arm_smmu_domain *smmu_domain = to_smmu_domain(domain);
struct arm_smmu_cfg
On 1/20/20 7:10 PM, Suravee Suthikulpanit wrote:
On 1/17/2020 5:08 PM, Joerg Roedel wrote:
Adding Suravee, who wrote the IOMMU Perf Counter code.
On Tue, Jan 14, 2020 at 08:12:20AM -0700, Shuah Khan wrote:
init_iommu_perf_ctr() clobbers the register when it checks write access
to IOMMU perf
On Tue, Jan 21, 2020 at 02:36:19PM +, Robin Murphy wrote:
> On 16/12/2019 4:37 pm, Jordan Crouse wrote:
> >Add support to enable split pagetables (TTBR1) if the supporting driver
> >requests it via the DOMAIN_ATTR_SPLIT_TABLES flag. When enabled, the driver
> >will set up the TTBR0 and TTBR1
On Tue, Jan 21, 2020 at 3:11 AM Robin Murphy wrote:
>
> On 18/12/2019 4:39 am, Cong Wang wrote:
> > The IOVA cache algorithm implemented in IOMMU code does not
> > exactly match the original algorithm described in the paper
> > "Magazines and Vmem: Extending the Slab Allocator to Many
> > CPUs
On Tue, Jan 21, 2020 at 1:52 AM Robin Murphy wrote:
>
> On 18/12/2019 4:39 am, Cong Wang wrote:
> > If the magazine is empty, iova_magazine_free_pfns() should
> > be a nop, however it misses the case of mag->size==0. So we
> > should just call iova_magazine_empty().
> >
> > This should reduce the
On 21/01/2020 5:11 pm, Jordan Crouse wrote:
[...]
I'm looking at iommu_aux_attach_device() and friends, and it appears pretty
achievable to hook that up in a workable manner, even if it's just routed
straight through to the impl to only work within qcom-specific parameters to
begin with. I
29 matches
Mail list logo