Hi Aleksey,
On 17.01.2017 16:14, Aleksey Makarov wrote:
Enable the Extended Stream ID feature when available.
This patch on top of series "KVM PCIe/MSI passthrough on ARM/ARM64
and IOVA reserved regions" by Eric Auger [1] allows to passthrough
an external PCIe network card on a ThunderX server
> Subject: Re: [PATCH v8 3/9] perf/amd/iommu: Misc fix up perf_iommu_read
Please be a bit more thorough when writing your commit messages. What is
a "misc fix up"? Perhaps it is ok for a quick'n'dirty local patch but
not when it is for upstream.
Also, function names end with "()" to denote they'r
On Sun, Jan 15, 2017 at 09:36:10AM +0700, Suravee Suthikulpanit wrote:
> Peter,
>
> On 1/11/17 18:57, Peter Zijlstra wrote:
> >On Mon, Jan 09, 2017 at 09:33:41PM -0600, Suravee Suthikulpanit wrote:
> >>This patch contains the following minor fixup:
> >> * Fixed overflow handling since u64 delta w
Hi Tomasz,
On 01/19/2017 11:55 AM, Tomasz Nowicki wrote:
> Hi Aleksey,
>
> On 17.01.2017 16:14, Aleksey Makarov wrote:
>> Enable the Extended Stream ID feature when available.
>>
>> This patch on top of series "KVM PCIe/MSI passthrough on ARM/ARM64
>> and IOVA reserved regions" by Eric Auger [1]
On 19.01.2017 11:57, Aleksey Makarov wrote:
Hi Tomasz,
On 01/19/2017 11:55 AM, Tomasz Nowicki wrote:
Hi Aleksey,
On 17.01.2017 16:14, Aleksey Makarov wrote:
Enable the Extended Stream ID feature when available.
This patch on top of series "KVM PCIe/MSI passthrough on ARM/ARM64
and IOVA reser
It is the time we have the real 16-bit Stream ID user, which is the
ThunderX. Its IO topology uses 1:1 map for Requester ID to Stream ID
translation for each root complex which allows to get full 16-bit
Stream ID. Firmware assigns bus IDs that are greater than 128 (0x80)
to some buses under PEM (e
Hi Sricharan,
On Fri, Jan 06, 2017 at 04:24:00PM +, Lorenzo Pieralisi wrote:
> On Thu, Jan 05, 2017 at 08:21:53PM +0530, Sricharan wrote:
> > Hi,
> >
> > [...]
> >
> > >>>
> > >>> With the thinking of taking this series through, would it be fine if i
> > >>> cleanup the pci configure hanging
From: Laurent Pinchart
Failures to look up an IOMMU when parsing the DT iommus property need to
be handled separately from the .of_xlate() failures to support deferred
probing.
The lack of a registered IOMMU can be caused by the lack of a driver for
the IOMMU, the IOMMU device probe not having b
From: Laurent Pinchart
As part of moving DMA initializing to probe time the
of_dma_deconfigure() function will need to be called from different
source files. Make it public and move it to drivers/of/device.c where
the of_dma_configure() function is.
Signed-off-by: Laurent Pinchart
---
* No cha
From: Robin Murphy
IOMMU configuration represents unchanging properties of the hardware,
and as such should only need happen once in a device's lifetime, but
the necessary interaction with the IOMMU device and driver complicates
exactly when that point should be.
Since the only reasonable tool a
This series calls the dma ops configuration for the devices
at a generic place so that it works for all busses.
The dma_configure_ops for a device is now called during
the device_attach callback just before the probe of the
bus/driver is called. Similarly dma_deconfigure is called during
device/dri
From: Laurent Pinchart
Invalid dma-ranges values should be worked around when retrieving the
DMA range in of_dma_get_range(), not by all callers of the function.
This isn't much of a problem now that we have a single caller, but that
situation will change when moving DMA configuration to device p
From: Robin Murphy
In preparation for some upcoming cleverness, rework the control flow in
of_iommu_configure() to minimise duplication and improve the propogation
of errors. It's also as good a time as any to switch over from the
now-just-a-compatibility-wrapper of_iommu_get_ops() to using the g
From: Lorenzo Pieralisi
The IOMMU probe deferral implementation requires a mechanism to detect
if drivers for SMMU components are built-in in the kernel to detect
whether IOMMU configuration for a given device should be deferred (ie
SMMU drivers present but still not probed) or not (drivers not p
With all the DT based devices getting their dma ops configured
during probe time to have the right iommu setup, let us do the
same for acpi based devices as well.
Configuring DMA ops at probe time will allow deferring device probe when
the IOMMU isn't available yet. The dma_configure for the devic
This is an equivalent to the DT's handling of the iommu master's probe
with deferred probing when the corrsponding iommu is not probed yet.
The lack of a registered IOMMU can be caused by the lack of a driver for
the IOMMU, the IOMMU device probe not having been performed yet, having
been deferred,
From: Lorenzo Pieralisi
The IORT linker section introduced by commit 34ceea275f62
("ACPI/IORT: Introduce linker section for IORT entries probing")
was needed to make sure SMMU drivers are registered (and therefore
probed) in the kernel before devices using the SMMU have a chance
to probe in turn.
With arch_setup_dma_ops now being called late during device's probe after
the device's iommu is probed, the notifier trick required to handle the
early setup of dma_ops before the iommu group gets created is not
required. So removing the notifier's here.
Signed-off-by: Sricharan R
[rm: clean up e
From: Robin Murphy
Now that the appropriate ordering is enforced via profe-deferral of
masters in core code, rip it all out and bask in the simplicity.
Signed-off-by: Robin Murphy
[Sricharan: Rebased on top of ACPI IORT SMMU series]
Signed-off-by: Sricharan R
---
* No change
drivers/iommu/a
Hi Lorenzo,
>-Original Message-
>From: linux-arm-kernel [mailto:linux-arm-kernel-boun...@lists.infradead.org]
>On Behalf Of Lorenzo Pieralisi
>Sent: Thursday, January 19, 2017 8:11 PM
>To: Sricharan
>Cc: linux-arm-...@vger.kernel.org; j...@8bytes.org; will.dea...@arm.com;
>iommu@lists.l
Configuring DMA ops at probe time will allow deferring device probe when
the IOMMU isn't available yet. The dma_configure for the device is
now called from the generic device_attach callback just before the
bus/driver probe is called. This way, configuring the DMA ops for the
device would be called
On Thu, Jan 19, 2017 at 05:36:36PM +0300, Aleksey Makarov wrote:
> It is the time we have the real 16-bit Stream ID user, which is the
> ThunderX. Its IO topology uses 1:1 map for Requester ID to Stream ID
> translation for each root complex which allows to get full 16-bit
> Stream ID. Firmware as
On Mon, Jan 16, 2017 at 08:16:07AM +0100, Tomasz Nowicki wrote:
> The goal of erratum #27704 workaround was to make sure that ASIDs and VMIDs
> are unique across all SMMU instances on affected Cavium systems.
>
> Currently, the workaround code partitions ASIDs and VMIDs by increasing
> global cavi
On Thu, Jan 19, 2017 at 08:35:52PM +0530, Sricharan R wrote:
> From: Robin Murphy
>
> Now that the appropriate ordering is enforced via profe-deferral of
> masters in core code, rip it all out and bask in the simplicity.
>
> Signed-off-by: Robin Murphy
> [Sricharan: Rebased on top of ACPI IORT
On Thu, Jan 19, 2017 at 08:35:51PM +0530, Sricharan R wrote:
> With arch_setup_dma_ops now being called late during device's probe after
> the device's iommu is probed, the notifier trick required to handle the
> early setup of dma_ops before the iommu group gets created is not
> required. So remov
On Thu, Jan 19, 2017 at 08:35:54PM +0530, Sricharan R wrote:
> With all the DT based devices getting their dma ops configured
> during probe time to have the right iommu setup, let us do the
> same for acpi based devices as well.
>
> Configuring DMA ops at probe time will allow deferring device pr
On Thu, Jan 19, 2017 at 08:35:49PM +0530, Sricharan R wrote:
> Configuring DMA ops at probe time will allow deferring device probe when
> the IOMMU isn't available yet. The dma_configure for the device is
> now called from the generic device_attach callback just before the
> bus/driver probe is cal
On Thu, Jan 19, 2017 at 08:35:52PM +0530, Sricharan R wrote:
> From: Robin Murphy
>
> Now that the appropriate ordering is enforced via profe-deferral of
> masters in core code, rip it all out and bask in the simplicity.
>
> Signed-off-by: Robin Murphy
> [Sricharan: Rebased on top of ACPI IORT
Currently alloc_contig_range assumes that the compaction should
be done with the default GFP_KERNEL flags. This is probably
right for all current uses of this interface, but may change as
CMA is used in more use-cases (including being the default DMA
memory allocator on some platforms).
Change the
The callers of the DMA alloc functions already provide the proper
context GFP flags. Make sure to pass them through to the CMA
allocator, to make the CMA compaction context aware.
Signed-off-by: Lucas Stach
---
arch/arm/mm/dma-mapping.c | 16 +---
arch/arm64/mm/dma-mapping.c
Most users of this interface just want to use it with the default
GFP_KERNEL flags, but for cases where DMA memory is allocated it may
be called from a different context.
No functional change yet, just passing through the flag to the
underlying alloc_contig_range function.
Signed-off-by: Lucas St
On 19/01/17 15:05, Sricharan R wrote:
> Configuring DMA ops at probe time will allow deferring device probe when
> the IOMMU isn't available yet. The dma_configure for the device is
> now called from the generic device_attach callback just before the
> bus/driver probe is called. This way, configur
On 19/01/17 16:50, Lorenzo Pieralisi wrote:
> On Thu, Jan 19, 2017 at 08:35:52PM +0530, Sricharan R wrote:
>> From: Robin Murphy
>>
>> Now that the appropriate ordering is enforced via profe-deferral of
>> masters in core code, rip it all out and bask in the simplicity.
>>
>> Signed-off-by: Robin
Hi all,
A number of people have expressed interest in having the SMMU come up in
a passthrough configuration, and then allow subsequent translation for
things such as VFIO. Rather than do this in each SMMU driver, it's much
cleaner to allow the default domain to be configured to be something other
In preparation for allowing the default domain type to be overridden,
this patch adds support for IOMMU_DOMAIN_IDENTITY domains to the
ARM SMMU driver.
An identity domain is created by placing the corresponding S2CR
registers into "bypass" mode, which allows transactions to flow through
the SMMU w
The arm64 DMA-mapping implementation sets the DMA ops to the IOMMU DMA
ops if we detect that an IOMMU is present for the master and the DMA
ranges are valid.
In the case when the IOMMU domain for the device is not of type
IOMMU_DOMAIN_DMA, then we have no business swizzling the ops, since
we're no
In preparation for allowing the default domain type to be overridden,
this patch adds support for IOMMU_DOMAIN_IDENTITY domains to the
ARM SMMUv3 driver.
An identity domain is created by placing the corresponding stream table
entries into "bypass" mode, which allows transactions to flow through
th
The ARM SMMU drivers provide a DOMAIN_ATTR_NESTING domain attribute,
which allows callers of the IOMMU API to request that the page table
for a domain is installed at stage-2, if supported by the hardware.
Since setting this attribute only makes sense for UNMANAGED domains,
this patch returns -ENO
The IOMMU core currently initialises the default domain for each group
to IOMMU_DOMAIN_DMA, under the assumption that devices will use
IOMMU-backed DMA ops by default. However, in some cases it is desirable
for the DMA ops to bypass the IOMMU for performance reasons, reserving
use of translation fo
On 19/01/17 18:19, Will Deacon wrote:
> The ARM SMMU drivers provide a DOMAIN_ATTR_NESTING domain attribute,
> which allows callers of the IOMMU API to request that the page table
> for a domain is installed at stage-2, if supported by the hardware.
>
> Since setting this attribute only makes sens
On Mon, Jan 16, 2017 at 01:23:31AM -0600, Suravee Suthikulpanit wrote:
> Introduce amd_iommu_get_num_iommus(), which returns the value of
> amd_iommus_present, then replaces the direct access to the variable
^
which
> which is now declared as static.
>
> Th
On 19/01/17 18:19, Will Deacon wrote:
> In preparation for allowing the default domain type to be overridden,
> this patch adds support for IOMMU_DOMAIN_IDENTITY domains to the
> ARM SMMU driver.
>
> An identity domain is created by placing the corresponding S2CR
> registers into "bypass" mode, wh
On 19/01/17 18:19, Will Deacon wrote:
> In preparation for allowing the default domain type to be overridden,
> this patch adds support for IOMMU_DOMAIN_IDENTITY domains to the
> ARM SMMUv3 driver.
>
> An identity domain is created by placing the corresponding stream table
> entries into "bypass"
On 19/01/17 18:19, Will Deacon wrote:
> The arm64 DMA-mapping implementation sets the DMA ops to the IOMMU DMA
> ops if we detect that an IOMMU is present for the master and the DMA
> ranges are valid.
>
> In the case when the IOMMU domain for the device is not of type
> IOMMU_DOMAIN_DMA, then we
On Thu, Jan 19, 2017 at 05:49:58PM +, Robin Murphy wrote:
> On 19/01/17 15:05, Sricharan R wrote:
> > Configuring DMA ops at probe time will allow deferring device probe when
> > the IOMMU isn't available yet. The dma_configure for the device is
> > now called from the generic device_attach cal
Following LPC discussions, we now report reserved regions through
the iommu-group sysfs reserved_regions attribute file.
Reserved regions are populated through the IOMMU get_resv_region
callback (former get_dm_regions), now implemented by amd-iommu,
intel-iommu and arm-smmu:
- the intel-iommu repo
We want to extend the callbacks used for dm regions and
use them for reserved regions. Reserved regions can be
- directly mapped regions
- regions that cannot be iommu mapped (PCI host bridge windows, ...)
- MSI regions (because they belong to another address space or because
they are not transla
From: Robin Murphy
IOMMU domain users such as VFIO face a similar problem to DMA API ops
with regard to mapping MSI messages in systems where the MSI write is
subject to IOMMU translation. With the relevant infrastructure now in
place for managed DMA domains, it's actually really simple for other
Introduce iommu_get_group_resv_regions whose role consists in
enumerating all devices from the group and collecting their
reserved regions. The list is sorted and overlaps between
regions of the same type are handled by merging the regions.
Signed-off-by: Eric Auger
Reviewed-by: Tomasz Nowicki
T
We introduce a new field to differentiate the reserved region
types and specialize the apply_resv_region implementation.
Legacy direct mapped regions have IOMMU_RESV_DIRECT type.
We introduce 2 new reserved memory types:
- IOMMU_RESV_MSI will characterize MSI regions that are mapped
- IOMMU_RESV_R
As we introduced new reserved region types which do not require
mapping, let's make sure we only map direct mapped regions.
Signed-off-by: Eric Auger
Reviewed-by: Tomasz Nowicki
Tested-by: Tomasz Nowicki
Tested-by: Bharat Bhushan
---
v3 -> v4:
- use region's type and reword commit message an
Introduce a new helper serving the purpose to allocate a reserved
region. This will be used in iommu driver implementing reserved
region callbacks.
Signed-off-by: Eric Auger
Reviewed-by: Tomasz Nowicki
Tested-by: Tomasz Nowicki
Tested-by: Bharat Bhushan
---
v3 -> v4:
- add INIT_LIST_HEAD(®io
A new iommu-group sysfs attribute file is introduced. It contains
the list of reserved regions for the iommu-group. Each reserved
region is described on a separate line:
- first field is the start IOVA address,
- second is the end IOVA address,
- third is the type.
Signed-off-by: Eric Auger
Teste
This new function checks whether all MSI irq domains
implement IRQ remapping. This is useful to understand
whether VFIO passthrough is safe with respect to interrupts.
On ARM typically an MSI controller can sit downstream
to the IOMMU without preventing VFIO passthrough.
As such any assigned devic
We introduce two new enum values for the irq domain flag:
- IRQ_DOMAIN_FLAG_MSI indicates the irq domain corresponds to
an MSI domain
- IRQ_DOMAIN_FLAG_MSI_REMAP indicates the irq domain has MSI
remapping capabilities.
Those values will be useful to check all MSI irq domains have
MSI remapping
Now we have a flag value indicating an IRQ domain implements MSI,
let's set it on msi_create_irq_domain().
Signed-off-by: Eric Auger
Reviewed-by: Marc Zyngier
Tested-by: Tomasz Nowicki
Tested-by: Bharat Bhushan
---
v7 -> v8
- Added Marc's R-b
v6: new
---
kernel/irq/msi.c | 4 ++--
1 file c
When attaching a group to the container, check the group's
reserved regions and test whether the IOMMU translates MSI
transactions. If yes, we initialize an IOVA allocator through
the iommu_get_msi_cookie API. This will allow the MSI IOVAs
to be transparently allocated on MSI controller's compose()
This patch registers the MSI and HT regions as non mappable
reserved regions. They will be exposed in the iommu-group sysfs.
For direct-mapped regions let's also use iommu_alloc_resv_region().
Signed-off-by: Eric Auger
---
v6 -> v7:
- use IOMMU_RESV_RESERVED
v5: creation
---
drivers/iommu/amd
The get() populates the list with the MSI IOVA reserved window.
At the moment an arbitray MSI IOVA window is set at 0x800
of size 1MB. This will allow to report those info in iommu-group
sysfs.
Signed-off-by: Eric Auger
Acked-by: Will Deacon
Reviewed-by: Tomasz Nowicki
---
v7 -> v8:
- ad
This patch registers the [FEE0_h - FEF0_000h] 1MB MSI
range as a reserved region and RMRR regions as direct regions.
This will allow to report those reserved regions in the
iommu-group sysfs.
Signed-off-by: Eric Auger
---
v6 -> v7:
- report RMRR regions as direct regions
- Due to the usage
The get() populates the list with the MSI IOVA reserved window.
At the moment an arbitray MSI IOVA window is set at 0x800
of size 1MB. This will allow to report those info in iommu-group
sysfs.
Signed-off-by: Eric Auger
Reviewed-by: Tomasz Nowicki
Tested-by: Tomasz Nowicki
Tested-by: Bhara
The GICv3 ITS is MSI remapping capable. Let's advertise
this property so that VFIO passthrough can assess IRQ safety.
Signed-off-by: Eric Auger
Reviewed-by: Marc Zyngier
Reviewed-by: Tomasz Nowicki
Tested-by: Tomasz Nowicki
Tested-by: Bharat Bhushan
---
v7 -> v8:
- added Marc's R-b
---
dri
In case the IOMMU translates MSI transactions (typical case
on ARM), we check MSI remapping capability at IRQ domain
level. Otherwise it is checked at IOMMU level.
At this stage the arm-smmu-(v3) still advertise the
IOMMU_CAP_INTR_REMAP capability at IOMMU level. This will be
removed in subsequent
IOMMU_CAP_INTR_REMAP has been advertised in arm-smmu(-v3) although
on ARM this property is not attached to the IOMMU but rather is
implemented in the MSI controller (GICv3 ITS).
Now vfio_iommu_type1 checks MSI remapping capability at MSI controller
level, let's correct this.
Signed-off-by: Eric A
Hi Lorenzo,
>On Thu, Jan 19, 2017 at 08:35:54PM +0530, Sricharan R wrote:
>> With all the DT based devices getting their dma ops configured
>> during probe time to have the right iommu setup, let us do the
>> same for acpi based devices as well.
>>
>> Configuring DMA ops at probe time will allow d
Hi Lorenzo,
>-Original Message-
>From: Lorenzo Pieralisi [mailto:lorenzo.pieral...@arm.com]
>Sent: Thursday, January 19, 2017 10:18 PM
>To: Sricharan R
>Cc: robin.mur...@arm.com; will.dea...@arm.com; j...@8bytes.org;
>iommu@lists.linux-foundation.org; linux-arm-
>ker...@lists.infradead.o
Hi Robin,
>On 19/01/17 15:05, Sricharan R wrote:
>> Configuring DMA ops at probe time will allow deferring device probe when
>> the IOMMU isn't available yet. The dma_configure for the device is
>> now called from the generic device_attach callback just before the
>> bus/driver probe is called. Th
Hi,
>
>> > pci_bus_add_devices(platform/amba)(_device_create/driver_register)
>> >| |
>> > pci_bus_add_device (device_add/driver_register)
>> >| |
>> > device_attach device_initial_probe
>> >|
Hi Robin,
>-Original Message-
>From: linux-arm-msm-ow...@vger.kernel.org
>[mailto:linux-arm-msm-ow...@vger.kernel.org] On Behalf Of Robin Murphy
>Sent: Thursday, January 19, 2017 11:28 PM
>To: Lorenzo Pieralisi ; Sricharan R
>
>Cc: will.dea...@arm.com; j...@8bytes.org; iommu@lists.linux-
69 matches
Mail list logo
