When attaching domain to a group of mediated devices which
all have the domain type attributes set to ATTACH_PARENT,
we should attach domain to the parent PCI device instead
of mdev device itself.
Cc: Ashok Raj
Cc: Jacob Pan
Cc: Kevin Tian
Cc: Liu Yi L
Signed-off-by: Sanjay Kumar
This adds support to return the default pasid associated with
an auxiliary domain. The PCI device which is bound with this
domain should use this value as the pasid for all DMA requests
of the subset of device which is isolated and protected with
this domain.
Cc: Ashok Raj
Cc: Jacob Pan
Cc:
A parent device might create different types of mediated
devices. For example, a mediated device could be created
by the parent device with full isolation and protection
provided by the IOMMU. One usage case could be found on
Intel platforms where a mediated device is an assignable
subset of a
This adds the support to determine the domain type of a group
of mediated devices according to the domain type attribute of
each device.
Cc: Ashok Raj
Cc: Jacob Pan
Cc: Kevin Tian
Cc: Liu Yi L
Signed-off-by: Sanjay Kumar
Signed-off-by: Lu Baolu
---
drivers/vfio/vfio_iommu_type1.c | 47
If a domain is attaching to a group which includes the
mediated devices, it should attach to the mdev parent
of each mdev. This adds a helper for attaching domain
to group, no matter a PCI physical device or mediated
devices which are derived from a PCI physical device.
Cc: Ashok Raj
Cc: Jacob
When multiple domains per device has been enabled by the
device driver, the device will tag the default PASID for
the domain to all DMA traffics out of the subset of this
device; and the IOMMU should translate the DMA requests
in PASID granularity.
This extends the
Add iommu ops for enabling and disabling multiple domains
for a device.
Cc: Ashok Raj
Cc: Jacob Pan
Cc: Kevin Tian
Cc: Liu Yi L
Signed-off-by: Lu Baolu
---
drivers/iommu/intel-iommu.c | 36
include/linux/intel-iommu.h | 1 +
2 files changed, 37
Otherwise, there will be a build warning:
drivers/iommu/amd_iommu.c:3083:2: warning: enumeration value
'IOMMU_CAP_AUX_DOMAIN' not handled in switch [-Wswitch]
There is no functional change.
Signed-off-by: Lu Baolu
---
drivers/iommu/amd_iommu.c | 2 ++
1 file changed, 2 insertions(+)
diff
Sharing a physical PCI device in a finer-granularity way
is becoming a consensus in the industry. IOMMU vendors
are also engaging efforts to support such sharing as well
as possible. Among the efforts, the capability of support
finer-granularity DMA isolation is a common requirement
due to the
Hi,
The Mediate Device is a framework for fine-grained physical device
sharing across the isolated domains. Currently the mdev framework
is designed to be independent of the platform IOMMU support. As the
result, the DMA isolation relies on the mdev parent device in a
vendor specific way.
There
Add the response to IOMMU_CAP_AUX_DOMAIN capability query
through iommu_capable(). Return true if IOMMUs support the
scalable mode, return false otherwise.
Cc: Ashok Raj
Cc: Jacob Pan
Cc: Kevin Tian
Cc: Liu Yi L
Signed-off-by: Lu Baolu
---
drivers/iommu/intel-iommu.c | 31
Deferred invalidation is an ECS specific feature. It will not be
supported when IOMMU works in scalable mode. As we deprecated the
ECS support, remove deferred invalidation and cleanup the code.
Cc: Ashok Raj
Cc: Jacob Pan
Cc: Kevin Tian
Cc: Liu Yi L
Signed-off-by: Lu Baolu
Reviewed-by:
This patch enables the current SVA (Shared Virtual Address)
implementation to work in the scalable mode.
Cc: Ashok Raj
Cc: Jacob Pan
Cc: Kevin Tian
Cc: Liu Yi L
Signed-off-by: Sanjay Kumar
Signed-off-by: Lu Baolu
Reviewed-by: Ashok Raj
---
drivers/iommu/intel-iommu.c | 40
This adds the interfaces to setup or tear down the structures
for first level page table translation.
Cc: Ashok Raj
Cc: Jacob Pan
Cc: Kevin Tian
Cc: Liu Yi L
Signed-off-by: Sanjay Kumar
Signed-off-by: Lu Baolu
Reviewed-by: Ashok Raj
---
drivers/iommu/intel-pasid.c | 89
This patch enables the translation for requests without PASID in
the scalable mode by setting up the root and context entries.
Cc: Ashok Raj
Cc: Jacob Pan
Cc: Kevin Tian
Cc: Liu Yi L
Signed-off-by: Sanjay Kumar
Signed-off-by: Lu Baolu
Reviewed-by: Ashok Raj
---
drivers/iommu/intel-iommu.c
So that the pasid related info, such as the pasid table and the
maximum of pasid could be used during setting up scalable mode
context.
Cc: Ashok Raj
Cc: Jacob Pan
Cc: Kevin Tian
Cc: Liu Yi L
Signed-off-by: Lu Baolu
Reviewed-by: Ashok Raj
---
drivers/iommu/intel-iommu.c | 14 +++---
when the scalable mode is enabled, there is no second level
page translation pointer in the context entry any more (for
DMA request without PASID). Instead, a new RID2PASID field
is introduced in the context entry. Software can choose any
PASID value to set RID2PASID and then setup the translation
Vt-d spec rev3.0 (section 6.2.3.1) requires that each pasid
entry for first-level or pass-through translation should be
programmed with a domain id different from those used for
second-level or nested translation. It is recommended that
software could use a same domain id for all first-only and
This adds the interfaces to setup or tear down the structures
for second level page table translations. This includes types
of second level only translation and pass through.
Cc: Ashok Raj
Cc: Jacob Pan
Cc: Kevin Tian
Cc: Liu Yi L
Signed-off-by: Sanjay Kumar
Signed-off-by: Lu Baolu
So that they could also be used in other source files.
Cc: Ashok Raj
Cc: Jacob Pan
Cc: Kevin Tian
Cc: Liu Yi L
Signed-off-by: Lu Baolu
Reviewed-by: Ashok Raj
---
drivers/iommu/intel-iommu.c | 43 -
include/linux/intel-iommu.h | 43
In scalable mode, pasid structure is a two level table with
a pasid directory table and a pasid table. Any pasid entry
can be identified by a pasid value in below way.
1
9 6 5 0
.---.---.
| PASID| |
Intel vt-d spec rev3.0 requires software to use 256-bit
descriptors in invalidation queue. As the spec reads in
section 6.5.2:
Remapping hardware supporting Scalable Mode Translations
(ECAP_REG.SMTS=1) allow software to additionally program
the width of the descriptors (128-bits or 256-bits) that
Hi,
Intel vt-d rev3.0 [1] introduces a new translation mode called
'scalable mode', which enables PASID-granular translations for
first level, second level, nested and pass-through modes. The
vt-d scalable mode is the key ingredient to enable Scalable I/O
Virtualization (Scalable IOV) [2] [3],
The Intel vt-d spec rev3.0 introduces a new translation
mode called scalable mode, which enables PASID-granular
translations for first level, second level, nested and
pass-through modes. At the same time, the previous
Extended Context (ECS) mode is deprecated (no production
ever implements ECS).
On Wed, Aug 29, 2018 at 6:23 AM Vivek Gautam
wrote:
>
> On Wed, Aug 29, 2018 at 2:05 PM Vivek Gautam
> wrote:
> >
> > Hi Rob,
> >
> >
> > On 8/29/2018 2:04 AM, Rob Herring wrote:
> > > On Mon, Aug 27, 2018 at 04:25:50PM +0530, Vivek Gautam wrote:
> > >> Add bindings doc for Qcom's smmu-v2
On Wed, Aug 29, 2018 at 08:23:58AM +0200, Christoph Hellwig wrote:
> Fix warnings and regressions from requiring a dma mask.
With this series applied, I see the following in my sh4 boot tests.
sb 1-1: new full-speed USB device number 2 using sm501-usb
sm501-usb sm501-usb: OHCI Unrecoverable
The function dma_set_max_seg_size() can return either 0 on success or
-EIO on error. Change its return type from unsigned int to int to
capture this.
Signed-off-by: Niklas Söderlund
---
include/linux/dma-mapping.h | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git
On Fri, Aug 24, 2018 at 12:11:23PM +0100, Robin Murphy wrote:
> On 24/08/18 07:53, Christoph Hellwig wrote:
>> When a device has a DMA offset the dma capable result will change due
>> to the difference between the physical and DMA address. Take that into
>> account.
>
> The "phys_to_dma(...,
On Wed, Aug 29, 2018 at 2:05 PM Vivek Gautam
wrote:
>
> Hi Rob,
>
>
> On 8/29/2018 2:04 AM, Rob Herring wrote:
> > On Mon, Aug 27, 2018 at 04:25:50PM +0530, Vivek Gautam wrote:
> >> Add bindings doc for Qcom's smmu-v2 implementation.
> >>
> >> Signed-off-by: Vivek Gautam
> >> Reviewed-by: Tomasz
Hi Rob,
On 8/29/2018 2:04 AM, Rob Herring wrote:
On Mon, Aug 27, 2018 at 04:25:50PM +0530, Vivek Gautam wrote:
Add bindings doc for Qcom's smmu-v2 implementation.
Signed-off-by: Vivek Gautam
Reviewed-by: Tomasz Figa
Tested-by: Srinivas Kandagatla
---
Changes since v14:
- This is a new
On Wed, Aug 29, 2018 at 8:24 AM Christoph Hellwig wrote:
> Fix warnings and regressions from requiring a dma mask.
Applied all three patches and took a few ARM systems for a test ride:
Tested-by: Linus Walleij
Yours,
Linus Walleij
___
iommu mailing
We still treat devices without a DMA mask as defaulting to 32-bits for
both mask, but a few releases ago we've started warning about such
cases, as they require special cases to work around this sloppyness.
Add a dma_mask field to struct platform_object so that we can initialize
the dma_mask
Fix warnings and regressions from requiring a dma mask.
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
From: Linus Walleij
commit a5516219b102 ("of/platform: Initialise default DMA masks") sets up
the coherent_dma_mask of platform devices created from the device tree,
but fails to do the same for AMBA (PrimeCell) devices.
This leads to a regression in kernel v4.19-rc1 triggering the
This keeps the historic default behavior for devices without a DMA mask,
but removes the warning about a lacking DMA mask for doing DMA without
a mask.
Reported-by: Meelis Roos
Tested-by: Meelis Roos
Signed-off-by: Christoph Hellwig
---
arch/sparc/kernel/of_device_32.c | 5 +
35 matches
Mail list logo
