https://git.kernel.org/pub/scm/linux/kernel/git/joro/iommu.git/commit/?h=x86/amd=7a5dbf3ab2f04905cf8468c66fcdbfb643068bcb
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
On Tue, Apr 23, 2019 at 12:03 PM dann frazier
wrote:
>
> On Tue, Apr 23, 2019 at 5:32 AM Robin Murphy wrote:
> >
> > On 17/04/2019 21:48, dann frazier wrote:
> > > hey,
> > >I'm seeing an issue on a couple of arm64 systems[*] where they spew
> > > ~10K "cma: cma_alloc: alloc failed" messages
To convert to/from cache types and granularities between generic and
VT-d specific counterparts, a 2D arrary is used. Introduce the limits
to help define the converstion array size.
Signed-off-by: Jacob Pan
---
include/uapi/linux/iommu.h | 2 ++
1 file changed, 2 insertions(+)
diff --git
Use combined macro for_each_svm_dev() to simplify SVM device iteration.
Suggested-by: Andy Shevchenko
Signed-off-by: Jacob Pan
---
drivers/iommu/intel-svm.c | 76 ++-
1 file changed, 36 insertions(+), 40 deletions(-)
diff --git
When Shared Virtual Memory is exposed to a guest via vIOMMU, extended
IOTLB invalidation may be passed down from outside IOMMU subsystems.
This patch adds invalidation functions that can be used for additional
translation cache types.
Signed-off-by: Jacob Pan
---
drivers/iommu/dmar.c|
When supporting guest SVA with emulated IOMMU, the guest PASID
table is shadowed in VMM. Updates to guest vIOMMU PASID table
will result in PASID cache flush which will be passed down to
the host as bind guest PASID calls.
For the SL page tables, it will be harvested from device's
default domain
When Shared Virtual Address (SVA) is enabled for a guest OS via
vIOMMU, we need to provide invalidation support at IOMMU API and driver
level. This patch adds Intel VT-d specific function to implement
iommu passdown invalidate API for shared virtual address.
The use case is for supporting caching
Nested translation mode is supported in VT-d 3.0 Spec.CH 3.8.
With PASID granular translation type set to 0x11b, translation
result from the first level(FL) also subject to a second level(SL)
page table translation. This mode is used for SVA virtualization,
where FL performs guest virtual to guest
Sometimes, IOASID allocation must be handled by platform specific
code. The use cases are guest vIOMMU and pvIOMMU where IOASIDs need
to be allocated by the host via enlightened or paravirt interfaces.
This patch adds an extension to the IOASID allocator APIs such that
platform drivers can
From: Lu Baolu
If Intel IOMMU runs in caching mode, a.k.a. virtual IOMMU, the
IOMMU driver should rely on the emulation software to allocate
and free PASID IDs. The Intel vt-d spec revision 3.0 defines a
register set to support this. This includes a capability register,
a virtual command
Guest shared virtual address (SVA) may require host to shadow guest
PASID tables. Guest PASID can also be allocated from the host via
enlightened interfaces. In this case, guest needs to bind the guest
mm, i.e. cr3 in guest phisical address to the actual PASID table in
the host IOMMU. Nesting will
Make use of generic IOASID code to manage PASID allocation,
free, and lookup.
Signed-off-by: Jacob Pan
---
drivers/iommu/Kconfig | 1 +
drivers/iommu/intel-iommu.c | 9 -
drivers/iommu/intel-pasid.c | 36
drivers/iommu/intel-svm.c | 41
Move domainer helper to header to be used by SVA code.
Signed-off-by: Jacob Pan
---
drivers/iommu/intel-iommu.c | 6 --
include/linux/intel-iommu.h | 6 ++
2 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/iommu/intel-iommu.c b/drivers/iommu/intel-iommu.c
index
IDR is to be replaced by XArray, keep up with the changes.
XArray has internal locking for normal APIs used here, also removed
radix tree related preload.
Suggested-by: Ira Weiny
Signed-off-by: Jacob Pan
---
drivers/base/ioasid.c | 29 -
1 file changed, 12
From: Jean-Philippe Brucker
Some devices might support multiple DMA address spaces, in particular
those that have the PCI PASID feature. PASID (Process Address Space ID)
allows to share process address spaces with devices (SVA), partition a
device into VM-assignable entities (VFIO mdev) or
From: "Liu, Yi L"
In any virtualization use case, when the first translation stage
is "owned" by the guest OS, the host IOMMU driver has no knowledge
of caching structure updates unless the guest invalidation activities
are trapped by the virtualizer and passed down to the host.
Since the
When VT-d driver runs in the guest, PASID allocation must be
performed via virtual command interface. This patch register a
custom IOASID allocator which takes precedence over the default
IDR based allocator. The resulting IOASID allocation will always
come from the host. This ensures that PASID
In virtualization use case, when a guest is assigned
a PCI host device, protected by a virtual IOMMU on the guest,
the physical IOMMU must be programmed to be consistent with
the guest mappings. If the physical IOMMU supports two
translation stages it makes sense to program guest mappings
onto the
Device faults detected by IOMMU can be reported outside the IOMMU
subsystem for further processing. This patch introduces
a generic device fault data structure.
The fault can be either an unrecoverable fault or a page request,
also referred to as a recoverable fault.
We only care about non
Traditionally, device specific faults are detected and handled within
their own device drivers. When IOMMU is enabled, faults such as DMA
related transactions are detected by IOMMU. There is no generic
reporting mechanism to report faults back to the in-kernel device
driver or the guest OS in case
DMA faults can be detected by IOMMU at device level. Adding a pointer
to struct device allows IOMMU subsystem to report relevant faults
back to the device driver for further handling.
For direct assigned device (or user space drivers), guest OS holds
responsibility to handle and respond per device
Shared virtual address (SVA), a.k.a, Shared virtual memory (SVM) on Intel
platforms allow address space sharing between device DMA and applications.
SVA can reduce programming complexity and enhance security.
This series is intended to enable SVA virtualization, i.e. shared guest
application
Hello,
> -Original Message-
> From: Christoph Hellwig
> Sent: Monday, April 22, 2019 9:11 PM
>
> On Mon, Apr 22, 2019 at 07:51:25PM +0300, laurentiu.tu...@nxp.com wrote:
> > From: Laurentiu Tudor
> >
> > If possible / available call into the DMA API to get a proper iommu
> > mapping
On Tue, 23 Apr 2019 23:38:16 +0200
Borislav Petkov wrote:
> But exactly this - *having* to do rst formatting would mean a lot of
> getting used to and people writing something which is not necessarily
> correct rst and someone else fixing up after them.
Remember that most of our docs are 99%
On Tue, Apr 23, 2019 at 05:05:02PM -0300, Mauro Carvalho Chehab wrote:
> That's my view about how that specific file would be after
> converted to ReST:
>
>
> https://git.linuxtv.org/mchehab/experimental.git/tree/Documentation/x86/x86_64/mm.rst?h=convert_rst_renames
>
> I don't have any
On Tue, 23 Apr 2019 17:19:44 -0300
Mauro Carvalho Chehab wrote:
> Anyway, one of the things that occurred to me is that maybe
> some scripting work or a ReST extension could do something to parse
> "Documentation/foo" as :doc:`Documentation/foo` without needing to
> explicitly use any ReST
Em Tue, 23 Apr 2019 11:53:49 -0600
Jonathan Corbet escreveu:
> On Tue, 23 Apr 2019 19:11:58 +0200
> Peter Zijlstra wrote:
>
> > Look at crap like this:
> >
> > "The memory allocations via :c:func:`kmalloc`, :c:func:`vmalloc`,
> > :c:func:`kmem_cache_alloc` and"
> >
> > That should've been
Em Tue, 23 Apr 2019 19:20:06 +0200
Borislav Petkov escreveu:
> On Tue, Apr 23, 2019 at 07:11:58PM +0200, Peter Zijlstra wrote:
> > I know I'm an odd duck; but no. They're _less_ accessible for me, as
> > both a reader and author. They look 'funny' when read as a text file
> > (the only way it
These checks were intended to handle devices not mapped by the IOMMU.
Since the AMD IOMMU driver uses per-device dma_ops these functions can
no longer be called by direct mapped devices. So these checks aren't
needed anymore.
Signed-off-by: Tom Murphy
---
drivers/iommu/amd_iommu.c | 10
On 23/04/2019 19:05, Stefano Stabellini wrote:
> On Tue, 23 Apr 2019, Juergen Gross wrote:
>> Instead of always calling xen_destroy_contiguous_region() in case the
>> memory is DMA-able for the used device, do so only in case it has been
>> made DMA-able via xen_create_contiguous_region() before.
On Tue, Apr 23, 2019 at 11:53:49AM -0600, Jonathan Corbet wrote:
> > Look at crap like this:
> >
> > "The memory allocations via :c:func:`kmalloc`, :c:func:`vmalloc`,
> > :c:func:`kmem_cache_alloc` and"
> >
> > That should've been written like:
> >
> > "The memory allocations via kmalloc(),
On Tue, Apr 23, 2019 at 5:32 AM Robin Murphy wrote:
>
> On 17/04/2019 21:48, dann frazier wrote:
> > hey,
> >I'm seeing an issue on a couple of arm64 systems[*] where they spew
> > ~10K "cma: cma_alloc: alloc failed" messages at boot. The errors are
> > non-fatal, and bumping up cma to a
On Tue, 23 Apr 2019 19:11:58 +0200
Peter Zijlstra wrote:
> When writing, I now have to be bothered about this format crap over just
> trying to write a coherent document.
Just write text, it'll all work out in the end :)
> Look at crap like this:
>
> "The memory allocations via
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?
___
iommu mailing list
iommu@lists.linux-foundation.org
- Accessible, usable docs are worth something in ROI
- https://www.writethedocs.org/
- https://read-the-docs.readthedocs.io/en/latest/
-
https://github.com/rtfd/readthedocs-docker-images/issues/47#issuecomment-485712800
- Dockerfile that extends from readthedocs/build:latest (which has
- Accessible, usable docs are worth something in ROI
- https://www.writethedocs.org/
- https://read-the-docs.readthedocs.io/en/latest/
-
https://github.com/rtfd/readthedocs-docker-images/issues/47#issuecomment-485712800
- Dockerfile that extends from readthedocs/build:latest (which has
On Tue, Apr 23, 2019 at 07:11:58PM +0200, Peter Zijlstra wrote:
> I know I'm an odd duck; but no. They're _less_ accessible for me, as
> both a reader and author. They look 'funny' when read as a text file
> (the only way it makes sense to read them; I spend 99% of my time on a
> computer looking
On Tue, Apr 23, 2019 at 10:30:53AM -0600, Jonathan Corbet wrote:
> On Tue, 23 Apr 2019 15:01:32 +0200
> Peter Zijlstra wrote:
>
> > But yes, I have 0 motivation to learn or abide by rst. It simply doesn't
> > give me anything in return. There is no upside, only worse text files :/
>
> So I
On Tue, 23 Apr 2019, Juergen Gross wrote:
> Instead of always calling xen_destroy_contiguous_region() in case the
> memory is DMA-able for the used device, do so only in case it has been
> made DMA-able via xen_create_contiguous_region() before.
>
> This will avoid a lot of
On Tue, 23 Apr 2019 15:01:32 +0200
Peter Zijlstra wrote:
> But yes, I have 0 motivation to learn or abide by rst. It simply doesn't
> give me anything in return. There is no upside, only worse text files :/
So I believe it gives even you one thing in return: documentation that is
more
Hi Simon,
On Thu, Apr 11, 2019 at 10:39 AM Simon Horman wrote:
> On Wed, Apr 03, 2019 at 08:21:48PM +0200, Geert Uytterhoeven wrote:
> > During PSCI system suspend, R-Car Gen3 SoCs are powered down, and all
> > IPMMU state is lost. Hence after s2ram, devices wired behind an IPMMU,
> > and
Em Tue, 23 Apr 2019 09:21:00 -0400
Mike Snitzer escreveu:
> On Tue, Apr 23 2019 at 9:01am -0400,
> Peter Zijlstra wrote:
>
> > On Tue, Apr 23, 2019 at 08:55:19AM -0400, Mike Snitzer wrote:
> > > On Tue, Apr 23 2019 at 4:31am -0400,
> > > Peter Zijlstra wrote:
> > >
> > > > On Mon, Apr
Hi Simon,
On Thu, Apr 11, 2019 at 10:12 AM Simon Horman wrote:
> On Thu, Apr 11, 2019 at 10:10:28AM +0200, Simon Horman wrote:
> > On Wed, Apr 03, 2019 at 08:21:43PM +0200, Geert Uytterhoeven wrote:
> > > As of commit 7af9a5fdb9e0ca33 ("iommu/ipmmu-vmsa: Use
> > >
On Thu, Apr 18, 2019 at 06:48:28PM -0500, Bjorn Helgaas wrote:
> To make progress on this, I think we need an ack from Joerg for the
> dma-iommu.c part, an ack from Ray or Scott for the pcie-iproc.c part,
> and an ack from Robin for the thing as a whole.
I wait for Robin to review the dma-iommu
On Tue, Apr 23, 2019 at 11:01:44AM +0100, Robin Murphy wrote:
> On 19/04/2019 09:23, Christoph Hellwig wrote:
>> On Thu, Apr 18, 2019 at 07:15:00PM +0100, Robin Murphy wrote:
>>> Still, I've worked in the vm_map_pages() stuff pending in MM and given them
>>> the same treatment to finish the
On 4/23/19 6:54 AM, Juergen Gross wrote:
> Instead of always calling xen_destroy_contiguous_region() in case the
> memory is DMA-able for the used device, do so only in case it has been
> made DMA-able via xen_create_contiguous_region() before.
>
> This will avoid a lot of
On 4/23/19 6:54 AM, Juergen Gross wrote:
> range_straddles_page_boundary() is open coding several macros from
> include/xen/page.h. Use those instead. Additionally there is no need
> to have check_pages_physically_contiguous() as a separate function as
> it is used only once, so merge it into
On 4/23/19 6:54 AM, Juergen Gross wrote:
> The condition in xen_swiotlb_free_coherent() for deciding whether to
> call xen_destroy_contiguous_region() is wrong: in case the region to
> be freed is not contiguous calling xen_destroy_contiguous_region() is
> the wrong thing to do: it would result in
On 23/04/2019 14:19, Robin Murphy wrote:
> On 23/04/2019 12:46, Marc Zyngier wrote:
>> On 23/04/2019 11:51, Julien Grall wrote:
>>> On 4/23/19 11:23 AM, Marc Zyngier wrote:
Hi Julien,
>>>
>>> Hi Marc,
>>>
On 18/04/2019 18:26, Julien Grall wrote:
> When an MSI doorbell is located
On Tue, Apr 23 2019 at 9:01am -0400,
Peter Zijlstra wrote:
> On Tue, Apr 23, 2019 at 08:55:19AM -0400, Mike Snitzer wrote:
> > On Tue, Apr 23 2019 at 4:31am -0400,
> > Peter Zijlstra wrote:
> >
> > > On Mon, Apr 22, 2019 at 10:27:45AM -0300, Mauro Carvalho Chehab wrote:
> > >
> > > >
On 23/04/2019 12:46, Marc Zyngier wrote:
On 23/04/2019 11:51, Julien Grall wrote:
On 4/23/19 11:23 AM, Marc Zyngier wrote:
Hi Julien,
Hi Marc,
On 18/04/2019 18:26, Julien Grall wrote:
When an MSI doorbell is located downstream of an IOMMU, it is required
to swizzle the physical address
On Tue, Apr 23, 2019 at 08:55:19AM -0400, Mike Snitzer wrote:
> On Tue, Apr 23 2019 at 4:31am -0400,
> Peter Zijlstra wrote:
>
> > On Mon, Apr 22, 2019 at 10:27:45AM -0300, Mauro Carvalho Chehab wrote:
> >
> > > .../{atomic_bitops.txt => atomic_bitops.rst} | 2 +
> >
> > What's happend to
On Tue, Apr 23 2019 at 4:31am -0400,
Peter Zijlstra wrote:
> On Mon, Apr 22, 2019 at 10:27:45AM -0300, Mauro Carvalho Chehab wrote:
>
> > .../{atomic_bitops.txt => atomic_bitops.rst} | 2 +
>
> What's happend to atomic_t.txt, also NAK, I still occationally touch
> these files.
Seems
Hi, Christoph,
On Mon, 2019-04-22 at 19:56 +0200, h...@lst.de wrote:
> On Wed, Apr 10, 2019 at 03:01:14PM +, Thomas Hellstrom wrote:
> > > So can you please respin a version acceptable to you and submit
> > > it
> > > for 5.1 ASAP? Otherwise I'll need to move ahead with the simple
> > >
On 23/04/2019 11:51, Julien Grall wrote:
> On 4/23/19 11:23 AM, Marc Zyngier wrote:
>> Hi Julien,
>
> Hi Marc,
>
>> On 18/04/2019 18:26, Julien Grall wrote:
>>> When an MSI doorbell is located downstream of an IOMMU, it is required
>>> to swizzle the physical address with an appropriately-mapped
On 17/04/2019 21:48, dann frazier wrote:
hey,
I'm seeing an issue on a couple of arm64 systems[*] where they spew
~10K "cma: cma_alloc: alloc failed" messages at boot. The errors are
non-fatal, and bumping up cma to a large enough size (~128M) gets rid
of them - but that seems suboptimal.
On Wed, Apr 17, 2019 at 07:24:39PM +0100, Jean-Philippe Brucker wrote:
> This series enables PCI ATS in SMMUv3. Changes since v2 [1]:
>
> * Fix build failure when building arm-smmu-v3 without CONFIG_PCI
> Patches 1 and 2 are new.
>
> * Only enable ATS if the root complex supports it. For the
On Mon, Apr 22, 2019 at 12:40:36PM +0530, Vivek Gautam wrote:
> Bits[15:0] in CBFRSYNRA register contain information about
> StreamID of the incoming transaction that generated the
> fault. Dump CBFRSYNRA register to get this info.
> This is specially useful in a distributed SMMU architecture
>
On Tue, 23 Apr 2019 at 13:13, Robin Murphy wrote:
>
> On 22/04/2019 08:10, Vivek Gautam wrote:
> > Bits[15:0] in CBFRSYNRA register contain information about
> > StreamID of the incoming transaction that generated the
> > fault. Dump CBFRSYNRA register to get this info.
> > This is specially
On 22/04/2019 08:10, Vivek Gautam wrote:
Bits[15:0] in CBFRSYNRA register contain information about
StreamID of the incoming transaction that generated the
fault. Dump CBFRSYNRA register to get this info.
This is specially useful in a distributed SMMU architecture
where multiple masters are
While hunting an issue in swiotlb-xen I stumbled over a wrong test
and found some areas for improvement.
Juergen Gross (3):
xen/swiotlb: fix condition for calling xen_destroy_contiguous_region()
xen/swiotlb: simplify range_straddles_page_boundary()
xen/swiotlb: remember having called
The condition in xen_swiotlb_free_coherent() for deciding whether to
call xen_destroy_contiguous_region() is wrong: in case the region to
be freed is not contiguous calling xen_destroy_contiguous_region() is
the wrong thing to do: it would result in inconsistent mappings of
multiple PFNs to the
Instead of always calling xen_destroy_contiguous_region() in case the
memory is DMA-able for the used device, do so only in case it has been
made DMA-able via xen_create_contiguous_region() before.
This will avoid a lot of xen_destroy_contiguous_region() calls for
64-bit capable devices.
As the
On 19/04/2019 05:29, Jacob Pan wrote:
> If it is OK with you, I will squash my changes into your ioasid patch
> and address the review comments in the v2 of this set, OK?
> i.e.
> [PATCH 02/18] ioasid: Add custom IOASID allocator
> [PATCH 03/18] ioasid: Convert ioasid_idr to XArray
That's fine
On 4/23/19 11:23 AM, Marc Zyngier wrote:
Hi Julien,
Hi Marc,
On 18/04/2019 18:26, Julien Grall wrote:
When an MSI doorbell is located downstream of an IOMMU, it is required
to swizzle the physical address with an appropriately-mapped IOVA for any
device attached to one of our DMA ops
Hi Julien,
On 18/04/2019 18:26, Julien Grall wrote:
> When an MSI doorbell is located downstream of an IOMMU, it is required
> to swizzle the physical address with an appropriately-mapped IOVA for any
> device attached to one of our DMA ops domain.
>
> At the moment, the allocation of the
On 19/04/2019 09:23, Christoph Hellwig wrote:
On Thu, Apr 18, 2019 at 07:15:00PM +0100, Robin Murphy wrote:
Still, I've worked in the vm_map_pages() stuff pending in MM and given them
the same treatment to finish the picture. Both x86_64_defconfig and
i386_defconfig do indeed compile and link
On 2019-04-19 10:07 am, Christoph Hellwig wrote:
On Thu, Apr 18, 2019 at 05:41:00PM +0100, Robin Murphy wrote:
From a very high level POV this looks ok, but sometimes a bit to
convoluted to me. The major issue why I went with the version I posted
is that I can cleanly ifdef out the remap
Hi Thomas,
On 4/18/19 8:28 PM, Thomas Gleixner wrote:
On Thu, 18 Apr 2019, Julien Grall wrote:
When an MSI doorbell is located downstream of an IOMMU, it is required
to swizzle the physical address with an appropriately-mapped IOVA for any
device attached to one of our DMA ops domain.
At the
On Mon, Apr 22, 2019 at 10:27:45AM -0300, Mauro Carvalho Chehab wrote:
> .../{atomic_bitops.txt => atomic_bitops.rst} | 2 +
What's happend to atomic_t.txt, also NAK, I still occationally touch
these files.
___
iommu mailing list
On Thu, 18 Apr 2019, Thomas Gleixner wrote:
> Replace the indirection through struct stack_trace by using the storage
> array based interfaces.
>
> Signed-off-by: Thomas Gleixner
Acked-by: Miroslav Benes
Feel free to take it through tip or let us know to pick it up.
Miroslav
Hi,
On 4/23/19 2:08 PM, Christoph Hellwig wrote:
Again, this and the option should not be in a specific iommu driver.
The option of whether bounce is ignored should be in the specific iommu
driver.
Why? As a user I could not care less which IOMMU driver my particular
system uses.
Looks
Using dev_get_drvdata directly.
Cc: Joerg Roedel
Cc: iommu@lists.linux-foundation.org
Signed-off-by: Kefeng Wang
---
drivers/iommu/omap-iommu.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/iommu/omap-iommu.c b/drivers/iommu/omap-iommu.c
index
Hi Christoph,
On 4/23/19 2:12 PM, Christoph Hellwig wrote:
On Tue, Apr 23, 2019 at 09:58:19AM +0800, Lu Baolu wrote:
554 for (i = 0; i < nslots; i++)
555 io_tlb_orig_addr[index+i] = orig_addr + (i <<
IO_TLB_SHIFT);
Could the tlb orig address set to
On Thu, Apr 18, 2019 at 10:41:35AM +0200, Thomas Gleixner wrote:
> Replace the indirection through struct stack_trace by using the storage
> array based interfaces.
>
> The original code in all printing functions is really wrong. It allocates a
> storage array on stack which is unused because
On Thu, Apr 18, 2019 at 06:26:06PM +0100, Julien Grall wrote:
> +int iommu_dma_prepare_msi(struct msi_desc *desc, phys_addr_t msi_addr)
> {
> + struct device *dev = msi_desc_to_dev(desc);
> struct iommu_domain *domain = iommu_get_domain_for_dev(dev);
> struct iommu_dma_cookie
On Tue, Apr 23, 2019 at 09:58:19AM +0800, Lu Baolu wrote:
> 554 for (i = 0; i < nslots; i++)
> 555 io_tlb_orig_addr[index+i] = orig_addr + (i <<
> IO_TLB_SHIFT);
>
> Could the tlb orig address set to PAGE_ALIGN_DOWN(orig_addr)? We
> couldn't assume the bounce buffer just
>> Again, this and the option should not be in a specific iommu driver.
>>
>
> The option of whether bounce is ignored should be in the specific iommu
> driver.
Why? As a user I could not care less which IOMMU driver my particular
system uses.
___
78 matches
Mail list logo
