Hi Thierry,
I happened upon this thread while looking into another thread [1].
> From: Thierry Reding
>
> On some platforms, the firmware will setup hardware to read from a given
> region of memory. One such example is a display controller that is
> scanning out a splash screen from physical
Uacce (Unified/User-space-access-intended Accelerator Framework) targets to
provide Shared Virtual Addressing (SVA) between accelerators and processes.
So accelerator can access any data structure of the main cpu.
This differs from the data sharing between cpu and io device, which share
data
Remove the module_param uacce_mode, which is not used currently.
Reviewed-by: Jonathan Cameron
Signed-off-by: Zhangfei Gao
Signed-off-by: Zhou Wang
---
drivers/crypto/hisilicon/zip/zip_main.c | 31 ++-
1 file changed, 6 insertions(+), 25 deletions(-)
diff --git
From: Kenneth Lee
Uacce (Unified/User-space-access-intended Accelerator Framework) targets to
provide Shared Virtual Addressing (SVA) between accelerators and processes.
So accelerator can access any data structure of the main cpu.
This differs from the data sharing between cpu and io device,
From: Kenneth Lee
Uacce (Unified/User-space-access-intended Accelerator Framework) is
a kernel module targets to provide Shared Virtual Addressing (SVA)
between the accelerator and process.
This patch add document to explain how it works.
Reviewed-by: Jonathan Cameron
Signed-off-by: Kenneth
The current DMA alias implementation requires the aliased device be on
the same PCI bus as the requester ID. This introduces an arch-specific
mechanism to point to another PCI device when doing mapping and
PCI DMA alias search.
Signed-off-by: Jon Derrick
---
arch/x86/pci/common.c | 7 +++
From: Christoph Hellwig
Various helpers need the pci_sysdata just to dereference a single field
in it. Add a little helper that returns the properly typed sysdata
pointer to require a little less boilerplate code.
Signed-off-by: Christoph Hellwig
[jonathan.derrick: added un-const cast]
Devices on the VMD domain use the VMD endpoint's requester ID and have
been relying on the VMD endpoint's DMA operations. The problem with this
was that VMD domain devices would use the VMD endpoint's attributes when
doing DMA and IOMMU mapping. We can be smarter about this by only using
the VMD
v2 Set:
https://lore.kernel.org/linux-iommu/1578580256-3483-1-git-send-email-jonathan.derr...@intel.com/T/#t
v1 Set:
https://lore.kernel.org/linux-iommu/20200107134125.gd30...@8bytes.org/T/#t
VMD currently works with VT-d enabled by pointing DMA and IOMMU actions at the
VMD endpoint. The
To be used by Intel-IOMMU code to find the correct domain.
CC: Christoph Hellwig
Signed-off-by: Jon Derrick
---
arch/x86/include/asm/pci.h | 5 ++---
drivers/pci/controller/vmd.c | 2 +-
2 files changed, 3 insertions(+), 4 deletions(-)
diff --git a/arch/x86/include/asm/pci.h
From: Christoph Hellwig
There are no users of X86_DEV_DMA_OPS left, so remove the code.
Reviewed-by: Jon Derrick
Signed-off-by: Christoph Hellwig
---
arch/x86/Kconfig | 3 ---
arch/x86/include/asm/device.h | 10 --
arch/x86/pci/common.c | 38
Hi Barret,
this looks good.
thanks
Yian
On 1/7/2020 11:16 AM, Barret Rhoden wrote:
The VT-d docs specify requirements for the RMRR entries base and end
(called 'Limit' in the docs) addresses.
This commit will cause the DMAR processing to skip any RMRR entries that
do not meet these
On Fri, 10 Jan 2020 09:15:45 +0800
Lu Baolu wrote:
> Hi Jacob,
>
> On 1/10/20 2:39 AM, Jacob Pan wrote:
> > On Wed, 18 Dec 2019 10:41:53 +0800
> > Lu Baolu wrote:
> >
> >> Hi again,
> >>
> >> On 12/17/19 3:24 AM, Jacob Pan wrote:
> >>> +/**
> >>> + * intel_pasid_setup_nested() - Set up
Hi Nicolas,
On 10/01/2020 17:19, Nicolas Saenz Julienne wrote:
Although the device tree might contain a reserved-memory DT node
dedicated as the default CMA pool, users might want to change CMA's
parameters using the kernel command line for debugging purposes and
whatnot. Honor this by
Although the device tree might contain a reserved-memory DT node
dedicated as the default CMA pool, users might want to change CMA's
parameters using the kernel command line for debugging purposes and
whatnot. Honor this by bypassing the reserved memory CMA setup, which
will ultimately end up
Hi Baolu,
any ideas here?
On Mon, Jan 06, 2020 at 04:43:05PM +0100, Frederik Schwan wrote:
> Hello people,
> since the introduction of the bounce buffer, a regression with TB3 devices
> has been introduced.
> USB devices attached to TB3 refuse to work since. Removing the commits that
>
On Fri, Jan 10, 2020 at 03:21:51PM +, Robin Murphy wrote:
> By VMSA rules, using Normal Non-Cacheable type with a shareability
> attribute of anything other than Outer Shareable is liable to lead into
> unpredictable territory. Although the SMMU architectures seem to give
> some slightly
Commit 05a648cd2dd7 ("iommu/io-pgtable-arm: Rationalise TCR handling")
reworked the way in which the TCR register value is returned from the
io-pgtable code when targetting the Arm long-descriptor format, in
preparation for allowing page-tables to target TTBR1.
As it turns out, the new interface
ARM_64_LPAE_S2_TCR_RES1 is intended to map to bit 31 of the VTCR register,
which is required to be set to 1 by the architecture. Unfortunately, we
accidentally treat this as a signed quantity which means we also set the
upper 32 bits of the VTCR to one, and they are required to be zero.
Treat
From: Robin Murphy
Now that we can correctly extract top-level indices without relying on
the remaining upper bits being zero, the only remaining impediments to
using a given table for TTBR1 are the address validation on map/unmap
and the awkward TCR translation granule format. Add a quirk so
The Armv7 ARM states that Normal, Non-cacheable mappings must explicitly
be marked as Outer Shareable in order to avoid UNPREDICTABLE behaviour:
| Overlaying the shareability attribute (B3-1377, ARM DDI 0406C.c)
|
| A memory region with a resultant memory type attribute of Normal, and
| a
Commit 9e6ea59f3ff3 ("iommu/io-pgtable: Support non-coherent page tables")
added support for non-coherent page-table walks to the Arm IOMMU page-table
backends. Unfortunately, it left the stage-2 allocator unchanged, so let's
hook that up in the same way.
Cc: Bjorn Andersson
Cc: Robin Murphy
Now that we have arm-smmu.h defining various SMMU constants, ensure that
they are namespaced with the ARM_SMMU_ prefix in order to avoid conflicts
with the CPU, such as the one we're currently bodging around with the
TCR.
Cc: Robin Murphy
Signed-off-by: Will Deacon
---
Hi all,
Last merge window, I merged most of the split page table prep work from Robin
[1], but there were a few patches left pending some rework. I think Robin was
hoping to get that done for 5.5, but what with the holidays falling like they
did and other committments, I've ended up picked up the
From: Robin Murphy
Although it's conceptually nice for the io_pgtable_cfg to provide a
standard VMSA TCR value, the reality is that no VMSA-compliant IOMMU
looks exactly like an Arm CPU, and they all have various other TCR
controls which io-pgtable can't be expected to understand. Thus since
From: Robin Murphy
TTBR1 values have so far been redundant since no users implement any
support for split address spaces. Crucially, though, one of the main
reasons for wanting to do so is to be able to manage each half entirely
independently, e.g. context-switching one set of mappings without
Make the SMR mask test more robust against SMR0 being live
at probe time, which might happen once we start supporting
firmware reservations for framebuffers and suchlike.
Signed-off-by: Robin Murphy
---
drivers/iommu/arm-smmu.c | 23 ++-
1 file changed, 18 insertions(+), 5
By VMSA rules, using Normal Non-Cacheable type with a shareability
attribute of anything other than Outer Shareable is liable to lead into
unpredictable territory. Although the SMMU architectures seem to give
some slightly stronger guarantees of Non-Cacheable output types becoming
implicitly Outer
On Mon, Nov 04, 2019 at 08:20:12PM +, Will Deacon wrote:
> On Mon, Nov 04, 2019 at 07:22:28PM +, Will Deacon wrote:
> > On Fri, Oct 25, 2019 at 07:08:29PM +0100, Robin Murphy wrote:
> > > Since the flawed first attempt, I've reworked things with an abstracted
> > > TCR and an explicit
On 2020/1/10 下午6:10, Jonathan Cameron wrote:
On Fri, 10 Jan 2020 14:55:39 +0800
"zhangfei@foxmail.com" wrote:
On 2020/1/10 上午1:38, Jonathan Cameron wrote:
On Mon, 16 Dec 2019 11:08:15 +0800
Zhangfei Gao wrote:
From: Kenneth Lee
Uacce (Unified/User-space-access-intended
On Thu, Dec 19, 2019 at 04:29:11PM -0800, Nicolin Chen wrote:
> According to Tegra X1 (Tegra210) TRM, the reset value of xusb_hostr
> field (bit [7:0]) should be 0x7a. So this patch simply corrects it.
>
> Signed-off-by: Nicolin Chen
> ---
> drivers/memory/tegra/tegra210.c | 2 +-
> 1 file
On 2020/1/10 下午6:08, Jonathan Cameron wrote:
On Fri, 10 Jan 2020 15:03:25 +0800
zhangfei wrote:
On 2020/1/10 上午1:49, Jonathan Cameron wrote:
On Mon, 16 Dec 2019 11:08:13 +0800
Zhangfei Gao wrote:
Uacce (Unified/User-space-access-intended Accelerator Framework) targets to
provide
On Fri, 10 Jan 2020 14:55:39 +0800
"zhangfei@foxmail.com" wrote:
> On 2020/1/10 上午1:38, Jonathan Cameron wrote:
> > On Mon, 16 Dec 2019 11:08:15 +0800
> > Zhangfei Gao wrote:
> >
> >> From: Kenneth Lee
> >>
> >> Uacce (Unified/User-space-access-intended Accelerator Framework) targets to
On Fri, 10 Jan 2020 15:03:25 +0800
zhangfei wrote:
> On 2020/1/10 上午1:49, Jonathan Cameron wrote:
> > On Mon, 16 Dec 2019 11:08:13 +0800
> > Zhangfei Gao wrote:
> >
> >> Uacce (Unified/User-space-access-intended Accelerator Framework) targets to
> >> provide Shared Virtual Addressing (SVA)
On a system with two host bridges(:00:00.0,:80:00.0), iommu
initialization fails with
DMAR: Device scope type does not match for :80:00.0
This is because the DMAR table reports this device as having scope 2
(ACPI_DMAR_SCOPE_TYPE_BRIDGE):
but the device has a type 0 PCI header:
35 matches
Mail list logo
