Hi Bharat,
On 12/01/2017 04:59, Bharat Bhushan wrote:
>
>
>> -Original Message-
>> From: Eric Auger [mailto:eric.au...@redhat.com]
>> Sent: Wednesday, January 11, 2017 3:12 PM
>> To: eric.au...@redhat.com; eric.auger@gmail.com;
>> christoffer.d...@linaro.org; marc.zyng...@arm.com;
>>
On Wed, Jan 11, 2017 at 10:28:05PM +, Bart Van Assche wrote:
> On Wed, 2017-01-11 at 21:31 +0100, gre...@linuxfoundation.org wrote:
> > That's a big sign that your patch series needs work. Break it up into
> > smaller pieces, it should be possible, which will make merges easier
> > (well, diff
On 11.01.2017 13:19, Robin Murphy wrote:
On 11/01/17 11:51, 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
> -Original Message-
> From: Eric Auger [mailto:eric.au...@redhat.com]
> Sent: Wednesday, January 11, 2017 3:12 PM
> To: eric.au...@redhat.com; eric.auger@gmail.com;
> christoffer.d...@linaro.org; marc.zyng...@arm.com;
> robin.mur...@arm.com; alex.william...@redhat.com;
> will.dea...@
On Wed, 2017-01-11 at 21:31 +0100, gre...@linuxfoundation.org wrote:
> That's a big sign that your patch series needs work. Break it up into
> smaller pieces, it should be possible, which will make merges easier
> (well, different in a way.)
Hello Greg,
Can you have a look at the attached patche
On Wed, Jan 11, 2017 at 4:36 AM, Will Deacon wrote:
> On Tue, Jan 10, 2017 at 02:20:13PM -0500, Rob Clark wrote:
>> On Tue, Jan 10, 2017 at 12:52 PM, Will Deacon wrote:
>> > On Fri, Jan 06, 2017 at 11:26:49AM -0500, Rob Clark wrote:
>> >> Hmm, well we install the fault handler on the iommu_domain
On Wed, Jan 11, 2017 at 06:17:03PM +, Bart Van Assche wrote:
> On Wed, 2017-01-11 at 07:48 +0100, Greg Kroah-Hartman wrote:
> > On Tue, Jan 10, 2017 at 04:56:41PM -0800, Bart Van Assche wrote:
> > > Several RDMA drivers, e.g. drivers/infiniband/hw/qib, use the CPU to
> > > transfer data between
On Wed, Jan 11, 2017 at 06:03:15PM +, Bart Van Assche wrote:
> On Wed, 2017-01-11 at 07:46 +0100, Greg Kroah-Hartman wrote:
> > On Tue, Jan 10, 2017 at 04:56:41PM -0800, Bart Van Assche wrote:
> > > Several RDMA drivers, e.g. drivers/infiniband/hw/qib, use the CPU to
> > > transfer data between
From: Tomasz Nowicki
Sent: Wednesday, January 11, 2017 3:51 AM
To: will.dea...@arm.com; robin.mur...@arm.com; mark.rutl...@arm.com;
j...@8bytes.org
Cc: linux-arm-ker...@lists.infradead.org; iommu@lists.linux-foundation.org;
linux-ker...@vger.kernel.org; Goutham,
On Wed, 2017-01-11 at 07:48 +0100, Greg Kroah-Hartman wrote:
> On Tue, Jan 10, 2017 at 04:56:41PM -0800, Bart Van Assche wrote:
> > Several RDMA drivers, e.g. drivers/infiniband/hw/qib, use the CPU to
> > transfer data between memory and PCIe adapter. Because of performance
> > reasons it is import
On Wed, 2017-01-11 at 07:46 +0100, Greg Kroah-Hartman wrote:
> On Tue, Jan 10, 2017 at 04:56:41PM -0800, Bart Van Assche wrote:
> > Several RDMA drivers, e.g. drivers/infiniband/hw/qib, use the CPU to
> > transfer data between memory and PCIe adapter. Because of performance
> > reasons it is import
On Mon, Jan 09, 2017 at 09:33:43PM -0600, Suravee Suthikulpanit wrote:
> The current amd_iommu_pc_get_set_reg_val() cannot support multi-IOMMU.
multiple IOMMUs.
> It is also confusing since it is trying to support set and get in
> one functi
On 10/01/17 11:57, Aleksey Makarov wrote:
> Enable the Extended Stream ID feature when available.
>
> This patch on top of series "[PATCH v7 00/19] KVM PCIe/MSI passthrough
> on ARM/ARM64 and IOVA reserved regions" by Eric Auger allows
> to passthrough an external PCIe network card on a ThunderX s
On 11/01/17 11:51, 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 cavium_smmu_context_count w
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 would lose the MSB sign bit.
Please explain.. afaict this actually introduces a bug.
> diff --git a/arch/x86/events/amd/iommu.c b/
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 cavium_smmu_context_count which in turn becomes the base ASID and VMID
value f
On Mon, Jan 09, 2017 at 09:33:41PM -0600, Suravee Suthikulpanit wrote:
> This patch contains the following minor fixup:
For the future: never say "this patch" in the commit message - just
explain *why* the patch is needed.
> * Fixed overflow handling since u64 delta would lose the MSB sign bit.
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
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()
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
---
v7 -> v8:
- added Marc's R-b
---
drivers/irqchip/irq-gic-v3-its.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/d
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
---
v7 -> v8
- Added Marc's R-b
v6: new
---
kernel/irq/msi.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/
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
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
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
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
---
v3 -> v4:
- do not handle PCI host bridge windows anymore
- encode
iommu/arm-smmu: Implement reserved region get/put callbacks
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: W
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
---
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
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
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
---
v3 -> v4:
- use region's type and reword commit message and title
---
drivers/iommu/iommu.c | 3 +++
1 file changed, 3 insertions(+)
diff -
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
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
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
---
v3 -> v4:
- add INIT_LIST_HEAD(®ion->list)
- use int for prot param and add int type param
- remove implementation ou
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
---
v6 -> v7:
- avoid merge o
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
On Tue, Jan 10, 2017 at 02:20:13PM -0500, Rob Clark wrote:
> On Tue, Jan 10, 2017 at 12:52 PM, Will Deacon wrote:
> > On Fri, Jan 06, 2017 at 11:26:49AM -0500, Rob Clark wrote:
> >> Hmm, well we install the fault handler on the iommu_domain.. perhaps
> >> maybe a combo of dts property (or decidin
Currently, amd_iommu_pc_get_max_[banks|counters]() use end-point
device ID to locate an IOMMU and check the reported max banks/counters.
The logic assumes that the IOMMU_BASE_DEVID belongs to the first IOMMU,
and uses it to acquire a reference to the first IOMMU, which does not work
on certain sys
On January 11, 2017 4:03:50 AM GMT+01:00, Suravee Suthikulpanit
wrote:
>
>Right Thanks for catching this. Do you want me to send out V8 with
>this fix?
Send only the corrected version of this patch please, as a reply to this
message.
Thanks.
--
Sent from a small device: formatting sux an
39 matches
Mail list logo
