On 7/17/20 2:45 AM, Jacob Pan wrote:
IOMMU generic layer already does sanity checks UAPI data for version
match and argsz range under generic information.
Remove the redundant version check from VT-d driver and check for vendor
specific data size.
Signed-off-by: Jacob Pan
Reviewed-by: Lu Baol
Some firmware found on various Qualcomm platforms traps writes to S2CR
of type BYPASS and writes FAULT into the register. This prevents us from
marking the streams for the display controller as BYPASS to allow
continued scanout of the screen through the initialization of the ARM
SMMU.
This adds a
With many Qualcomm platforms not having functional S2CR BYPASS a
temporary IOMMU domain, without translation, needs to be allocated in
order to allow these memory transactions.
Unfortunately the boot loader uses the first few context banks, so
rather than overwriting a active bank the last context
Turn all stream mappings marked as valid into BYPASS. This allows the
platform specific implementation to configure stream mappings to match
the boot loader's configuration for e.g. display to continue to function
through the reset of the SMMU.
Tested-by: John Stultz
Tested-by: Vinod Koul
Sugges
Firmware that traps writes to S2CR to translate BYPASS into FAULT also
ignores writes of type FAULT. As such booting with "disable_bypass" set
will result in all S2CR registers left as configured by the bootloader.
This has been seen to result in indeterministic results, as these
mappings might li
Expose the SMR and S2CR structs in the header file, to allow platform
specific implementations to populate/initialize the smrs and s2cr
arrays.
Tested-by: John Stultz
Tested-by: Vinod Koul
Signed-off-by: Bjorn Andersson
---
Changes since v1:
- Picked up tested-by
drivers/iommu/arm-smmu.c | 1
Based on previous attempts and discussions this is the latest attempt at
inheriting stream mappings set up by the bootloader, for e.g. boot splash or
efifb.
The first patch is an implementation of Robin's suggestion that we should just
mark the relevant stream mappings as BYPASS. Relying on someth
Before commit 587e6c10a7ce ("iommu/arm-smmu-v3: Reduce contention during
command-queue insertion"), msi polling perhaps performed better since
it could run outside the spin_lock_irqsave() while the code polling cons
reg was running in the lock.
But after the great reorganization of smmu queue, nei
Hi Jean,
On 7/16/20 5:39 PM, Jean-Philippe Brucker wrote:
> On Tue, Jul 14, 2020 at 10:12:49AM +, Liu, Yi L wrote:
>>> Have you verified that this doesn't break the existing usage of
>>> DOMAIN_ATTR_NESTING in drivers/vfio/vfio_iommu_type1.c?
>>
>> I didn't have ARM machine on my hand. But I c
As IOMMU UAPI gets extended, user data size may increase. To support
backward compatibiliy, this patch introduces a size field to each UAPI
data structures. It is *always* the responsibility for the user to fill in
the correct size. Padding fields are adjusted to ensure 8 byte alignment.
Specific
IOMMU generic layer already does sanity checks UAPI data for version
match and argsz range under generic information.
Remove the redundant version check from VT-d driver and check for vendor
specific data size.
Signed-off-by: Jacob Pan
---
drivers/iommu/intel/iommu.c | 3 +--
drivers/iommu/intel
IOMMU UAPI data has a user filled argsz field which indicates the data
length comes with the API call. User data is not trusted, argsz must be
validated based on the current kernel data size, mandatory data size,
and feature flags.
User data may also be extended, results in possible argsz increase
IOMMU UAPI is newly introduced to support communications between guest
virtual IOMMU and host IOMMU. There has been lots of discussions on how
it should work with VFIO UAPI and userspace in general.
This document is indended to clarify the UAPI design and usage. The
mechanics of how future extensi
IOMMU user API header was introduced to support nested DMA translation and
related fault handling. The current UAPI data structures consist of three
areas that cover the interactions between host kernel and guest:
- fault handling
- cache invalidation
- bind guest page tables, i.e. guest PASID
IOMMU UAPI data size is filled by the user space which must be validated
by ther kernel. To ensure backward compatibility, user data can only be
extended by either re-purpose padding bytes or extend the variable sized
union at the end. No size change is allowed before the union. Therefore,
the mini
Hi Chritoph,
On Fri, 2020-07-10 at 16:10 +0200, Nicolas Saenz Julienne wrote:
> There is no guarantee to CMA's placement, so allocating a zone specific
> atomic pool from CMA might return memory from a completely different
> memory zone. To get around this double check CMA's placement before
> all
Perhaps a silly question (I'm too engrossed in PMU world ATM to get properly
back up to speed on this), but couldn't this be done without cmpxchg anyway?
Instinctively it feels like instead of maintaining a literal software copy
of the prod value, we could resolve the "claim my slot in the queue"
On 2020-07-16 16:01, Christoph Hellwig wrote:
Make dir2name a little more readable and maintainable by using
named initializers.
Signed-off-by: Christoph Hellwig
---
kernel/dma/debug.c | 8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/kernel/dma/debug.c b/kernel/dma
On Mon, Jul 13, 2020 at 09:22:37PM +0100, Will Deacon wrote:
> > +static struct arm_smmu_ctx_desc *arm_smmu_share_asid(u16 asid)
> > +{
> > + struct arm_smmu_ctx_desc *cd;
> >
> > - xa_erase(&asid_xa, cd->asid);
> > + cd = xa_load(&asid_xa, asid);
> > + if (!cd)
> > + return NUL
Hi,
Thanks for reviewing, I think these 3 or 4 patches are the trickiest in
the whole SVA series
On Mon, Jul 13, 2020 at 04:46:23PM +0100, Will Deacon wrote:
> On Thu, Jun 18, 2020 at 05:51:17PM +0200, Jean-Philippe Brucker wrote:
> > diff --git a/arch/arm64/include/asm/mmu.h b/arch/arm64/include
On Tue, Jul 14, 2020 at 10:12:49AM +, Liu, Yi L wrote:
> > Have you verified that this doesn't break the existing usage of
> > DOMAIN_ATTR_NESTING in drivers/vfio/vfio_iommu_type1.c?
>
> I didn't have ARM machine on my hand. But I contacted with Jean
> Philippe, he confirmed no compiling issue
On Thu, Jul 16, 2020 at 09:50:53AM +0100, Will Deacon wrote:
> On Mon, Jul 13, 2020 at 11:19:17AM -0600, Jordan Crouse wrote:
> > On Mon, Jul 13, 2020 at 04:09:02PM +0100, Will Deacon wrote:
> > > On Fri, Jun 26, 2020 at 02:00:38PM -0600, Jordan Crouse wrote:
> > > > diff --git a/drivers/iommu/arm-
Make dir2name a little more readable and maintainable by using
named initializers.
Signed-off-by: Christoph Hellwig
---
kernel/dma/debug.c | 8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/kernel/dma/debug.c b/kernel/dma/debug.c
index 36c962a86bf25d..41e720c3ab20c5 1006
Applied to nvme-5.9.
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
On Thu, Jul 16, 2020 at 1:51 AM Will Deacon wrote:
>
> On Mon, Jul 13, 2020 at 11:19:17AM -0600, Jordan Crouse wrote:
> > On Mon, Jul 13, 2020 at 04:09:02PM +0100, Will Deacon wrote:
> > > On Fri, Jun 26, 2020 at 02:00:38PM -0600, Jordan Crouse wrote:
> > > > diff --git a/drivers/iommu/arm-smmu.h
On 16/07/2020 11:28, Will Deacon wrote:
On Thu, Jul 16, 2020 at 11:22:33AM +0100, Will Deacon wrote:
On Thu, Jul 16, 2020 at 11:19:41AM +0100, Will Deacon wrote:
On Tue, Jun 23, 2020 at 01:28:36AM +0800, John Garry wrote:
As mentioned in [0], the CPU may consume many cycles processing
arm_smmu
czw., 16 lip 2020 o 14:02 Will Deacon napisał(a):
>
> On Thu, Jul 16, 2020 at 01:00:43PM +0100, Will Deacon wrote:
> > On Wed, 15 Jul 2020 09:06:45 +0200, Tomasz Nowicki wrote:
> > > The series is meant to support SMMU for AP806 and a workaround
> > > for accessing ARM SMMU 64bit registers is the
On Sat, Jul 11, 2020 at 1:18 AM John Stultz wrote:
> This patch series provides exports and config tweaks to allow
> the qcom-pdc driver to be able to be configured as a permement
> modules (particularlly useful for the Android Generic Kernel
> Image efforts).
>
> This was part of a larger patch
On Thu, Jul 16, 2020 at 01:00:43PM +0100, Will Deacon wrote:
> On Wed, 15 Jul 2020 09:06:45 +0200, Tomasz Nowicki wrote:
> > The series is meant to support SMMU for AP806 and a workaround
> > for accessing ARM SMMU 64bit registers is the gist of it.
> >
> > For the record, AP-806 can't access SMMU
On Wed, 15 Jul 2020 09:06:45 +0200, Tomasz Nowicki wrote:
> The series is meant to support SMMU for AP806 and a workaround
> for accessing ARM SMMU 64bit registers is the gist of it.
>
> For the record, AP-806 can't access SMMU registers with 64bit width.
> This patches split the readq/writeq into
On 16/07/2020 12:22, Robin Murphy wrote:
On 2020-07-16 11:56, John Garry wrote:
On 16/07/2020 11:28, Will Deacon wrote:
On Thu, Jul 16, 2020 at 11:22:33AM +0100, Will Deacon wrote:
On Thu, Jul 16, 2020 at 11:19:41AM +0100, Will Deacon wrote:
On Tue, Jun 23, 2020 at 01:28:36AM +0800, John Garr
On Thu, Jul 16, 2020 at 12:22:05PM +0100, Robin Murphy wrote:
> On 2020-07-16 11:56, John Garry wrote:
> > On 16/07/2020 11:28, Will Deacon wrote:
> > > On Thu, Jul 16, 2020 at 11:22:33AM +0100, Will Deacon wrote:
> > > > On Thu, Jul 16, 2020 at 11:19:41AM +0100, Will Deacon wrote:
> > > > > On Tue
On 2020-07-16 11:56, John Garry wrote:
On 16/07/2020 11:28, Will Deacon wrote:
On Thu, Jul 16, 2020 at 11:22:33AM +0100, Will Deacon wrote:
On Thu, Jul 16, 2020 at 11:19:41AM +0100, Will Deacon wrote:
On Tue, Jun 23, 2020 at 01:28:36AM +0800, John Garry wrote:
As mentioned in [0], the CPU may
On 08/07/2020 13:16, Tomasz Figa wrote:
> On Wed, Jul 8, 2020 at 9:14 AM Xia Jiang wrote:
>>
>> On Tue, 2020-07-07 at 15:35 +0200, Tomasz Figa wrote:
>>> On Tue, Jul 7, 2020 at 8:47 AM Xia Jiang wrote:
On Tue, 2020-06-30 at 16:53 +, Tomasz Figa wrote:
> Hi Xia,
>
> On Tu
On 16/07/2020 11:28, Will Deacon wrote:
On Thu, Jul 16, 2020 at 11:22:33AM +0100, Will Deacon wrote:
On Thu, Jul 16, 2020 at 11:19:41AM +0100, Will Deacon wrote:
On Tue, Jun 23, 2020 at 01:28:36AM +0800, John Garry wrote:
As mentioned in [0], the CPU may consume many cycles processing
arm_smmu
On Thu, Jul 16, 2020 at 11:22:33AM +0100, Will Deacon wrote:
> On Thu, Jul 16, 2020 at 11:19:41AM +0100, Will Deacon wrote:
> > On Tue, Jun 23, 2020 at 01:28:36AM +0800, John Garry wrote:
> > > As mentioned in [0], the CPU may consume many cycles processing
> > > arm_smmu_cmdq_issue_cmdlist(). One
On 16/07/2020 11:20, Will Deacon wrote:
On Tue, Jun 23, 2020 at 01:28:40AM +0800, John Garry wrote:
It has been shown that the cmpxchg() for finding space in the cmdq can
be a bottleneck:
- for more CPUs contending the cmdq, the cmpxchg() will fail more often
- since the software-maintained cons
On Thu, Jul 16, 2020 at 11:19:41AM +0100, Will Deacon wrote:
> On Tue, Jun 23, 2020 at 01:28:36AM +0800, John Garry wrote:
> > As mentioned in [0], the CPU may consume many cycles processing
> > arm_smmu_cmdq_issue_cmdlist(). One issue we find is the cmpxchg() loop to
> > get space on the queue tak
On Tue, Jun 23, 2020 at 01:28:40AM +0800, John Garry wrote:
> It has been shown that the cmpxchg() for finding space in the cmdq can
> be a bottleneck:
> - for more CPUs contending the cmdq, the cmpxchg() will fail more often
> - since the software-maintained cons pointer is updated on the same 64b
On Tue, Jun 23, 2020 at 01:28:36AM +0800, John Garry wrote:
> As mentioned in [0], the CPU may consume many cycles processing
> arm_smmu_cmdq_issue_cmdlist(). One issue we find is the cmpxchg() loop to
> get space on the queue takes approx 25% of the cycles for this function.
>
> This series remov
On Mon, Jul 13, 2020 at 11:19:17AM -0600, Jordan Crouse wrote:
> On Mon, Jul 13, 2020 at 04:09:02PM +0100, Will Deacon wrote:
> > On Fri, Jun 26, 2020 at 02:00:38PM -0600, Jordan Crouse wrote:
> > > diff --git a/drivers/iommu/arm-smmu.h b/drivers/iommu/arm-smmu.h
> > > index 5f2de20e883b..d33cfe26b
Hi Jacob,
On 7/7/20 2:12 AM, Jacob Pan wrote:
> For guest requested IOTLB invalidation, address and mask are provided as
> part of the invalidation data. VT-d HW silently ignores any address bits
> below the mask. SW shall also allow such case but give warning if
> address does not align with the
On 2020-07-16 04:23, Makarand Pawagi wrote:
-Original Message-
From: Lorenzo Pieralisi
[...]
Anyway - you need to seek feedback from Marc on whether patches
11 and 12 are OK from an irqchip perspective, it is possible we can
take the rest
of the series independently if everyone agre
Hi Jacob,
On 7/7/20 2:12 AM, Jacob Pan wrote:
> DevTLB flush can be used for both DMA request with and without PASIDs.
> The former uses PASID#0 (RID2PASID), latter uses non-zero PASID for SVA
> usage.
>
> This patch adds a check for PASID value such that devTLB flush with
> PASID is used for SVA
Hi Jacob,
On 7/7/20 2:12 AM, Jacob Pan wrote:
> From: Liu Yi L
>
> Address information for device TLB invalidation comes from userspace
> when device is directly assigned to a guest with vIOMMU support.
> VT-d requires page aligned address. This patch checks and enforce
> address to be page alig
On 15.07.2020 12:36, Robin Murphy wrote:
On 2020-07-15 08:06, Tomasz Nowicki wrote:
Add specific compatible string for Marvell usage due to errata of
accessing 64bits registers of ARM SMMU, in AP806.
AP806 SoC uses the generic ARM-MMU500, and there's no specific
implementation of Marvell, this
On 15.07.2020 12:32, Robin Murphy wrote:
On 2020-07-15 08:06, Tomasz Nowicki wrote:
From: Hanna Hawa
Due to erratum #582743, the Marvell Armada-AP806 can't access 64bit to
ARM SMMUv2 registers.
Provide implementation relevant hooks:
- split the writeq/readq to two accesses of writel/readl.
-
47 matches
Mail list logo
