Hi Jean,
On 2018/10/20 2:11, Jean-Philippe Brucker wrote:
This is a first prototype adding auxiliary domain support to Arm SMMUv3,
following Lu Baolu's latest proposal for IOMMU aware mediated devices
[1]. It works, but the attach() API still doesn't feel right. See (2)
below.
Patch 1 adapts io
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 insertions(+),
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 in
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/drivers/i
Some devices might support multiple DMA address spaces, in particular
those that have the PCI PASID feature. PASID (Process Address Space ID)
allows to share process address spaces with devices (SVA), partition a
device into VM-assignable entities (VFIO mdev) or simply provide
multiple DMA address
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/drivers
The same set of functions, iommu_attach/detach_device/group, is used
both to change a device's domain (let's call it "main domain") and to
add auxiliary domains. The former is used by vfio-pci for example, to
assign the whole device to userspace. The latter is used by vfio-mdev to
assign partitions
This is a first prototype adding auxiliary domain support to Arm SMMUv3,
following Lu Baolu's latest proposal for IOMMU aware mediated devices
[1]. It works, but the attach() API still doesn't feel right. See (2)
below.
Patch 1 adapts iommu.c to the current proposal for auxiliary domains.
Patches
On Thu, Oct 11, 2018 at 03:26:57PM +0300, Stanimir Varbanov wrote:
> On 10/10/2018 08:08 PM, Will Deacon wrote:
> > On Wed, Oct 10, 2018 at 05:44:07PM +0300, Stanimir Varbanov wrote:
> >> Call iommu client translation fault handler(s).
> >>
> >> Signed-off-by: Stanimir Varbanov
> >> ---
> >> driv
On 08/10/2018 09:02, Christoph Hellwig wrote:
All architectures that support swiotlb also have a zone that backs up
these less than full addressing allocations (usually ZONE_DMA32).
Because of that it is rather pointless to fall back to the global swiotlb
buffer if the normal dma direct allocati
On 18/10/2018 12:48, John Garry wrote:
On 18/10/2018 12:19, Robin Murphy wrote:
On 18/10/18 11:55, John Garry wrote:
[...]
@@ -976,18 +1019,19 @@ static int __arm_smmu_cmdq_issue_sync(struct
arm_smmu_device *smmu)
{
u64 cmd[CMDQ_ENT_DWORDS];
unsigned long flags;
-bool wfe = !!(sm
On Fri, Oct 19, 2018 at 08:52:58AM +0200, Christoph Hellwig wrote:
> On Thu, Oct 18, 2018 at 08:37:15PM -0400, Konrad Rzeszutek Wilk wrote:
> > > > + if (!dma_capable(dev, dma_addr, size) ||
> > > > + swiotlb_force == SWIOTLB_FORCE) {
> > > > + trace_swiotlb_bounced(de
On Fri, Oct 19, 2018 at 08:04:25AM +0200, Christoph Hellwig wrote:
> On Thu, Oct 18, 2018 at 08:17:14PM -0400, Konrad Rzeszutek Wilk wrote:
> > On Mon, Oct 08, 2018 at 10:02:39AM +0200, Christoph Hellwig wrote:
> > > All properly written drivers now have error handling in the
> > > dma_map_single /
13 matches
Mail list logo