在 2021/6/10 下午7:47, Jason Gunthorpe 写道:
On Thu, Jun 10, 2021 at 10:00:01AM +0800, Jason Wang wrote:
在 2021/6/8 下午9:20, Jason Gunthorpe 写道:
On Tue, Jun 08, 2021 at 09:10:42AM +0800, Jason Wang wrote:
Well, this sounds like a re-invention of io_uring which has already worked
for multifds.
Hi Isaac,
Any update for this series? The iommu core part looks good to me and I
also have some patches for Intel IOMMU implementation of [un]map_pages.
Just wonder when could iommu core have this optimization.
Best regards,
baolu
On 4/9/21 1:13 AM, Isaac J. Manjarres wrote:
When unmapping a
Hi, Alex,
> From: Alex Williamson
> Sent: Thursday, June 10, 2021 11:39 PM
>
> On Wed, 9 Jun 2021 15:49:40 -0300
> Jason Gunthorpe wrote:
>
> > On Wed, Jun 09, 2021 at 10:27:22AM -0600, Alex Williamson wrote:
> >
> > > > > It is a kernel decision, because a fundamental task of the kernel is
Hi Krishna,
On 2021-06-11 06:07, Krishna Reddy wrote:
> No, the unmap latency is not just in some test case written, the issue
> is very real and we have workloads where camera is reporting frame
> drops because of this unmap latency in the order of 100s of milliseconds.
> And hardware team
> > No, the unmap latency is not just in some test case written, the issue
> > is very real and we have workloads where camera is reporting frame
> > drops because of this unmap latency in the order of 100s of milliseconds.
> > And hardware team recommends using ASID based invalidations for
> >
On 6/10/2021 10:41 PM, Linus Torvalds wrote:
>
> How about a patch like the attached? Does that fix things for you.
>
Yes, it fixes the caam driver regression.
Tested-by: Horia Geantă
on top of next-20210610.
Thank you,
Horia
___
iommu mai
On Wed, Jun 9, 2021 at 7:50 PM Xiyu Yang wrote:
>
> The reference counting issue happens in several exception handling paths
> of arm_smmu_iova_to_phys_hard(). When those error scenarios occur, the
> function forgets to decrease the refcount of "smmu" increased by
> arm_smmu_rpm_get(), causing a
From: Rob Clark
Wire up support to stall the SMMU on iova fault, and collect a devcore-
dump snapshot for easier debugging of faults.
Currently this is a6xx-only, but mostly only because so far it is the
only one using adreno-smmu-priv.
Signed-off-by: Rob Clark
---
From: Rob Clark
Add, via the adreno-smmu-priv interface, a way for the GPU to request
the SMMU to stall translation on faults, and then later resume the
translation, either retrying or terminating the current translation.
This will be used on the GPU side to "freeze" the GPU while we snapshot
From: Jordan Crouse
Use the new adreno-smmu-priv fault info function to get more SMMU
debug registers and print the current TTBR0 to debug per-instance
pagetables and figure out which GPU block generated the request.
Signed-off-by: Jordan Crouse
Signed-off-by: Rob Clark
---
From: Jordan Crouse
Add a callback in adreno-smmu-priv to read interesting SMMU
registers to provide an opportunity for a richer debug experience
in the GPU driver.
Signed-off-by: Jordan Crouse
Signed-off-by: Rob Clark
---
drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c | 17
From: Jordan Crouse
Call report_iommu_fault() to allow upper-level drivers to register their
own fault handlers.
Signed-off-by: Jordan Crouse
Signed-off-by: Rob Clark
Acked-by: Will Deacon
---
drivers/iommu/arm/arm-smmu/arm-smmu.c | 9 +++--
1 file changed, 7 insertions(+), 2
From: Rob Clark
This picks up an earlier series[1] from Jordan, and adds additional
support needed to generate GPU devcore dumps on iova faults. Original
description:
This is a stack to add an Adreno GPU specific handler for pagefaults. The first
patch starts by wiring up report_iommu_fault
On Thu, Jun 10, 2021 at 7:52 AM Horia Geantă wrote:
>
> Documentation/core-api/dma-api.rst explicitly allows for partial syncs:
> Synchronise a single contiguous or scatter/gather mapping for the CPU
> and device. With the sync_sg API, all the parameters must be the same
> as those passed into
On Thu, Jun 10, 2021 at 05:05:27PM +0200, Thierry Reding wrote:
> On Thu, Jun 10, 2021 at 04:23:56PM +0200, Krzysztof Kozlowski wrote:
> > On 10/06/2021 11:19, Thierry Reding wrote:
> > > On Tue, Jun 08, 2021 at 05:48:51PM +0100, Will Deacon wrote:
> > >> I can queue as much or as little of 2-6 as
On Thu, Jun 03, 2021 at 10:50:02AM +0200, Sven Peter wrote:
> DART (Device Address Resolution Table) is the iommu found on Apple
> ARM SoCs such as the M1.
>
> Signed-off-by: Sven Peter
> ---
> .../devicetree/bindings/iommu/apple,dart.yaml | 81 +++
> MAINTAINERS
On Tue, Jun 08, 2021 at 04:31:50PM +1000, David Gibson wrote:
> For the qemu case, I would imagine a two stage fallback:
>
> 1) Ask for the exact IOMMU capabilities (including pagetable
>format) that the vIOMMU has. If the host can supply, you're
>good
>
> 2) If not, ask
On 09/06/2021 09:15, Joerg Roedel wrote:
On Tue, Jun 08, 2021 at 09:18:25PM +0800, John Garry wrote:
Zhen Lei (3):
iommu: Enhance IOMMU default DMA mode build options
iommu/vt-d: Add support for IOMMU default DMA mode build options
iommu/amd: Add support for IOMMU default DMA mode
Hi Robin,
On 2021-06-10 20:59, Robin Murphy wrote:
On 2021-06-10 12:54, Sai Prakash Ranjan wrote:
Hi Robin,
On 2021-06-10 17:03, Robin Murphy wrote:
On 2021-06-10 10:36, Sai Prakash Ranjan wrote:
Hi Robin,
On 2021-06-10 14:38, Robin Murphy wrote:
On 2021-06-10 06:24, Sai Prakash Ranjan
On Wed, 9 Jun 2021 15:49:40 -0300
Jason Gunthorpe wrote:
> On Wed, Jun 09, 2021 at 10:27:22AM -0600, Alex Williamson wrote:
>
> > > > It is a kernel decision, because a fundamental task of the kernel is to
> > > > ensure isolation between user-space tasks as good as it can. And if a
> > > >
On 2021-06-10 12:54, Sai Prakash Ranjan wrote:
Hi Robin,
On 2021-06-10 17:03, Robin Murphy wrote:
On 2021-06-10 10:36, Sai Prakash Ranjan wrote:
Hi Robin,
On 2021-06-10 14:38, Robin Murphy wrote:
On 2021-06-10 06:24, Sai Prakash Ranjan wrote:
Hi Robin,
On 2021-06-10 00:14, Robin Murphy
On Thu, Jun 10, 2021 at 04:23:56PM +0200, Krzysztof Kozlowski wrote:
> On 10/06/2021 11:19, Thierry Reding wrote:
> > On Tue, Jun 08, 2021 at 05:48:51PM +0100, Will Deacon wrote:
> >> On Tue, Jun 08, 2021 at 04:38:48PM +0200, Thierry Reding wrote:
> >>> On Tue, Jun 08, 2021 at 01:01:29PM +0100,
On 6/8/2021 5:35 AM, Dominique MARTINET wrote:
> I'm not able to find any individual mails for Christoph's patches so
> replying to the PR.
>
The patch set is here:
https://lore.kernel.org/linux-iommu/20210207160327.2955490-1-...@lst.de
> In particular, this commit:
> Konrad Rzeszutek Wilk wrote
On 6/7/2021 10:56 PM, Tianyu Lan wrote:
On 6/7/2021 2:43 PM, Christoph Hellwig wrote:
On Sun, May 30, 2021 at 11:06:25AM -0400, Tianyu Lan wrote:
From: Tianyu Lan
For Hyper-V isolation VM with AMD SEV SNP, the bounce buffer(shared
memory)
needs to be accessed via extra address
On 10/06/2021 11:19, Thierry Reding wrote:
> On Tue, Jun 08, 2021 at 05:48:51PM +0100, Will Deacon wrote:
>> On Tue, Jun 08, 2021 at 04:38:48PM +0200, Thierry Reding wrote:
>>> On Tue, Jun 08, 2021 at 01:01:29PM +0100, Will Deacon wrote:
On Mon, Jun 07, 2021 at 10:49:10AM +0200, Krzysztof
Hi Vitaly:
Thanks for your review.
On 6/10/2021 5:47 PM, Vitaly Kuznetsov wrote:
diff --git a/arch/x86/include/asm/hyperv-tlfs.h
b/arch/x86/include/asm/hyperv-tlfs.h
index 606f5cc579b2..632281b91b44 100644
--- a/arch/x86/include/asm/hyperv-tlfs.h
+++
On 6/9/2021 8:46 PM, Joerg Roedel wrote:
On Sun, May 30, 2021 at 11:06:21AM -0400, Tianyu Lan wrote:
+void hv_ghcb_msr_write(u64 msr, u64 value)
+{
+ union hv_ghcb *hv_ghcb;
+ void **ghcb_base;
+ unsigned long flags;
+
+ if (!ms_hyperv.ghcb_base)
+
Hi Joerg：
Thanks for your review.
On 6/9/2021 8:38 PM, Joerg Roedel wrote:
On Sun, May 30, 2021 at 11:06:18AM -0400, Tianyu Lan wrote:
From: Tianyu Lan
Hyper-V exposes GHCB page via SEV ES GHCB MSR for SNP guest
to communicate with hypervisor. Map GHCB page for all
cpus to
On Thu, 2021-06-10 at 09:53 +0200, Matthias Brugger wrote:
> Hi Yong,
>
> On 12/05/2021 14:29, Yong Wu wrote:
> > On Wed, 2021-05-12 at 17:20 +0800, Hsin-Yi Wang wrote:
> >> On Sat, Apr 10, 2021 at 5:14 PM Yong Wu wrote:
> >>>
> >>> MediaTek IOMMU has already added the device_link between the
On Thu, Jun 10, 2021 at 12:33:56PM +0100, Robin Murphy wrote:
> On 2021-06-10 10:36, Sai Prakash Ranjan wrote:
> > Hi Robin,
> >
> > On 2021-06-10 14:38, Robin Murphy wrote:
> > > On 2021-06-10 06:24, Sai Prakash Ranjan wrote:
> > > > Hi Robin,
> > > >
> > > > On 2021-06-10 00:14, Robin Murphy
On Wed, 2021-05-26 at 08:41 +0300, Dafna Hirschfeld wrote:
> Hi
>
> On 10.04.21 12:11, Yong Wu wrote:
> > MediaTek IOMMU has already added the device_link between the consumer
> > and smi-larb device. If the drm device call the pm_runtime_get_sync,
> > the smi-larb's pm_runtime_get_sync also be
Hi Robin,
On 2021-06-10 17:03, Robin Murphy wrote:
On 2021-06-10 10:36, Sai Prakash Ranjan wrote:
Hi Robin,
On 2021-06-10 14:38, Robin Murphy wrote:
On 2021-06-10 06:24, Sai Prakash Ranjan wrote:
Hi Robin,
On 2021-06-10 00:14, Robin Murphy wrote:
On 2021-06-09 15:53, Sai Prakash Ranjan
On Thu, Jun 10, 2021 at 10:00:01AM +0800, Jason Wang wrote:
>
> 在 2021/6/8 下午9:20, Jason Gunthorpe 写道:
> > On Tue, Jun 08, 2021 at 09:10:42AM +0800, Jason Wang wrote:
> >
> > > Well, this sounds like a re-invention of io_uring which has already worked
> > > for multifds.
> > How so? io_uring is
On 2021-06-10 10:36, Sai Prakash Ranjan wrote:
Hi Robin,
On 2021-06-10 14:38, Robin Murphy wrote:
On 2021-06-10 06:24, Sai Prakash Ranjan wrote:
Hi Robin,
On 2021-06-10 00:14, Robin Murphy wrote:
On 2021-06-09 15:53, Sai Prakash Ranjan wrote:
Currently for iommu_unmap() of large
Tianyu Lan writes:
> From: Tianyu Lan
>
> In Isolation VM, all shared memory with host needs to mark visible
> to host via hvcall. vmbus_establish_gpadl() has already done it for
> netvsc rx/tx ring buffer. The page buffer used by vmbus_sendpacket_
> pagebuffer() still need to handle. Use DMA
Tianyu Lan writes:
> From: Tianyu Lan
>
> Add new hvcall guest address host visibility support. Mark vmbus
> ring buffer visible to host when create gpadl buffer and mark back
> to not visible when tear down gpadl buffer.
>
> Co-developed-by: Sunil Muthuswamy
> Signed-off-by: Tianyu Lan
> ---
Hi Robin,
On 2021-06-10 14:38, Robin Murphy wrote:
On 2021-06-10 06:24, Sai Prakash Ranjan wrote:
Hi Robin,
On 2021-06-10 00:14, Robin Murphy wrote:
On 2021-06-09 15:53, Sai Prakash Ranjan wrote:
Currently for iommu_unmap() of large scatter-gather list with page
size
elements, the majority
On Tue, Jun 08, 2021 at 05:48:51PM +0100, Will Deacon wrote:
> On Tue, Jun 08, 2021 at 04:38:48PM +0200, Thierry Reding wrote:
> > On Tue, Jun 08, 2021 at 01:01:29PM +0100, Will Deacon wrote:
> > > On Mon, Jun 07, 2021 at 10:49:10AM +0200, Krzysztof Kozlowski wrote:
> > > > This is the pull for
On 2021-06-10 06:24, Sai Prakash Ranjan wrote:
Hi Robin,
On 2021-06-10 00:14, Robin Murphy wrote:
On 2021-06-09 15:53, Sai Prakash Ranjan wrote:
Currently for iommu_unmap() of large scatter-gather list with page size
elements, the majority of time is spent in flushing of partial walks in
From: Joerg Roedel
A recent commit broke the build on 32-bit x86. The linker throws these
messages:
ld: drivers/iommu/intel/perf.o: in function `dmar_latency_snapshot':
perf.c:(.text+0x40c): undefined reference to `__udivdi3'
ld: perf.c:(.text+0x458): undefined reference
dma-iommu uses the address bounds described in domain->geometry during
IOVA allocation. The address size parameters of iommu_setup_dma_ops()
are useful for describing additional limits set by the platform
firmware, but aren't needed for drivers that call this function from
probe_finalize(). The
Passing a 64-bit address width to iommu_setup_dma_ops() is valid on
virtual platforms, but isn't currently possible. The overflow check in
iommu_dma_init_domain() prevents this even when @dma_base isn't 0. Pass
a limit address instead of a size, so callers don't have to fake a size
to work around
The ACPI Virtual I/O Translation Table describes topology of
para-virtual platforms, similarly to vendor tables DMAR, IVRS and IORT.
For now it describes the relation between virtio-iommu and the endpoints
it manages.
Three steps are needed to configure DMA of endpoints:
(1) acpi_viot_init():
With the VIOT support in place, x86 platforms can now use the
virtio-iommu.
Because the other x86 IOMMU drivers aren't yet ready to use the
acpi_dma_setup() path, x86 doesn't implement arch_setup_dma_ops() at the
moment. Similarly to Vt-d and AMD IOMMU, call iommu_setup_dma_ops() from
Add a driver for the ACPI VIOT table, which provides topology
information for para-virtual IOMMUs. Enable virtio-iommu on
non-devicetree platforms, including x86.
Since v3 [1] I fixed a build bug for !CONFIG_IOMMU_API. Joerg offered to
take this series through the IOMMU tree, which requires Acks
Extract the code that sets up the IOMMU infrastructure from IORT, since
it can be reused by VIOT. Move it one level up into a new
acpi_iommu_configure_id() function, which calls the IORT parsing
function which in turn calls the acpi_iommu_fwspec_init() helper.
Signed-off-by: Jean-Philippe Brucker
Extract generic DMA setup code out of IORT, so it can be reused by VIOT.
Keep it in drivers/acpi/arm64 for now, since it could break x86
platforms that haven't run this code so far, if they have invalid
tables.
Signed-off-by: Jean-Philippe Brucker
---
drivers/acpi/arm64/Makefile | 1 +
Hi Yong,
On 12/05/2021 14:29, Yong Wu wrote:
> On Wed, 2021-05-12 at 17:20 +0800, Hsin-Yi Wang wrote:
>> On Sat, Apr 10, 2021 at 5:14 PM Yong Wu wrote:
>>>
>>> MediaTek IOMMU has already added the device_link between the consumer
>>> and smi-larb device. If the vcodec device call the
On Fri, Jun 04, 2021 at 05:22:07PM +0200, Joerg Roedel wrote:
> On Thu, Jun 03, 2021 at 09:26:39AM +0200, Jean-Philippe Brucker wrote:
> > These are only defined when CONFIG_IOMMU_API is set. IORT uses them inside
> > an #ifdef, I can do the same. Maybe moving these two functions to a new
> >
On Thu, Jun 10, 2021 at 10:00:52AM +0800, Lu Baolu wrote:
> include/linux/intel-iommu.h| 44 +-
> drivers/iommu/intel/perf.h | 73
> include/trace/events/intel_iommu.h | 37 ++
> drivers/iommu/intel/debugfs.c | 111 +
> drivers/iommu/intel/dmar.c | 54 ++-
50 matches
Mail list logo
