Bit 1 of the IVFS IVInfo field indicates that IOMMU has been used for
pre-boot DMA protection.
Export this capability to allow other places in the kernel to be able to
check for it on AMD systems.
Cc: Robin Murphy
Link: https://www.amd.com/system/files/TechDocs/48882_IOMMU.pdf
Signed-off-by:
[Public]
> Between me trying to get rid of iommu_present() and Mario wanting to
> support the AMD equivalent of DMAR_PLATFORM_OPT_IN, scrutiny has
> shown
> that the iommu_dma_protection attribute is being far too optimistic.
> Even if an IOMMU might be present for some PCI segment in the system,
From: Robin Murphy Sent: Friday, March 18, 2022 4:08 AM
>
> On 2022-03-17 19:13, Michael Kelley (LINUX) wrote:
> > From: Robin Murphy Sent: Thursday, March 17, 2022
> 10:20 AM
> >>
> >> On 2022-03-17 16:25, Michael Kelley via iommu wrote:
> >>> Add a wrapper function to set dma_coherent,
From: Robin Murphy Sent: Friday, March 18, 2022 3:58 AM
>
> On 2022-03-18 05:12, Michael Kelley (LINUX) wrote:
> > From: Robin Murphy Sent: Thursday, March 17, 2022
> 10:15 AM
> >>
> >> On 2022-03-17 16:25, Michael Kelley via iommu wrote:
> >>> PCI pass-thru devices in a Hyper-V VM are
Between me trying to get rid of iommu_present() and Mario wanting to
support the AMD equivalent of DMAR_PLATFORM_OPT_IN, scrutiny has shown
that the iommu_dma_protection attribute is being far too optimistic.
Even if an IOMMU might be present for some PCI segment in the system,
that doesn't
VT-d's dmar_platform_optin() actually represents a combination of
properties fairly well standardised by Microsoft as "Pre-boot DMA
Protection" and "Kernel DMA Protection"[1]. As such, we can provide
interested consumers with an abstracted capability rather than
driver-specific interfaces that
OK, here's chapter 3 in the story of "but I really just want to
remove iommu_present()", which is the second go at this approach
on the Thunderbolt end, but now improving the IOMMU end as well
since the subtlety of why that still matters has been clarified.
Previous thread here:
iommufd can directly implement the /dev/vfio/vfio container IOCTLs by
mapping them into io_pagetable operations. Doing so allows the use of
iommufd by symliking /dev/vfio/vfio to /dev/iommufd. Allowing VFIO to
SET_CONTAINER using a iommufd instead of a container fd is a followup
series.
This is the basic infrastructure of a new miscdevice to hold the iommufd
IOCTL API.
It provides:
- A miscdevice to create file descriptors to run the IOCTL interface over
- A table based ioctl dispatch and centralized extendable pre-validation
step
- An xarray mapping user ID's to kernel
Cover the essential functionality of the iommufd with a directed
test. This aims to achieve reasonable functional coverage using the
in-kernel self test framework.
It provides a mock for the iommu_domain that allows it to run without any
HW and the mocking provides a way to directly validate that
iommufd is the user API to control the IOMMU subsystem as it relates to
managing IO page tables that point at user space memory.
It takes over from drivers/vfio/vfio_iommu_type1.c (aka the VFIO
container) which is the VFIO specific interface for a similar idea.
We see a broad need for extended
Add the four functions external drivers need to connect physical DMA to
the IOMMUFD:
iommufd_bind_pci_device() / iommufd_unbind_device()
Register the device with iommufd and establish security isolation.
iommufd_device_attach() / iommufd_device_detach()
Connect a bound device to a page table
The span iterator travels over the indexes of the interval_tree, not the
nodes, and classifies spans of indexes as either 'used' or 'hole'.
'used' spans are fully covered by nodes in the tree and 'hole' spans have
no node intersecting the span.
This is done greedily such that spans are maximally
Following the pattern of io_uring, perf, skb, and bpf iommfd will use
user->locked_vm for accounting pinned pages. Ensure the value is included
in the struct and export free_uid() as iommufd is modular.
user->locked_vm is the correct accounting to use for ulimit because it is
per-user, and the
This is the remainder of the IOAS data structure. Provide an object called
an io_pagetable that is composed of iopt_areas pointing at iopt_pages,
along with a list of iommu_domains that mirror the IOVA to PFN map.
At the top this is a simple interval tree of iopt_areas indicating the map
of IOVA
The hw_pagetable object exposes the internal struct iommu_domain's to
userspace. An iommu_domain is required when any DMA device attaches to an
IOAS to control the io page table through the iommu driver.
For compatibility with VFIO the hw_pagetable is automatically created when
a DMA device is
The top of the data structure provides an IO Address Space (IOAS) that is
similar to a VFIO container. The IOAS allows map/unmap of memory into
ranges of IOVA called iopt_areas. Domains and in-kernel users (like VFIO
mdevs) can be attached to the IOAS to access the PFNs that those IOVA
areas
Connect the IOAS to its IOCTL interface. This exposes most of the
functionality in the io_pagetable to userspace.
This is intended to be the core of the generic interface that IOMMUFD will
provide. Every IOMMU driver should be able to implement an iommu_domain
that is compatible with this generic
The iopt_pages which represents a logical linear list of PFNs held in
different storage tiers. Each area points to a slice of exactly one
iopt_pages, and each iopt_pages can have multiple areas and users.
The three storage tiers are managed to meet these objectives:
- If no iommu_domain or user
From: Kevin Tian
Add iommufd to the documentation tree.
Signed-off-by: Kevin Tian
Signed-off-by: Jason Gunthorpe
---
Documentation/userspace-api/index.rst | 1 +
Documentation/userspace-api/iommufd.rst | 224
2 files changed, 225 insertions(+)
create mode 100644
Hi Robin,
On Fri, Mar 18, 2022 at 03:15:19PM +, Robin Murphy wrote:
> > IMHO we should just trust the firmare provided information here
> > (otherwise we are screwed anyway as there is no way to tell if the
> > devices connected prior the OS can still do DMA), and use the external
> > facing
On 2022-03-18 14:47, mika.westerb...@linux.intel.com wrote:
On Fri, Mar 18, 2022 at 02:08:16PM +, Robin Murphy wrote:
On 2022-03-18 13:25, mika.westerb...@linux.intel.com wrote:
Hi Robin,
On Fri, Mar 18, 2022 at 12:01:42PM +, Robin Murphy wrote:
This adds quite a lot code and
Hi Lukas,
On Fri, Mar 18, 2022 at 03:51:21PM +0100, Lukas Wunner wrote:
> On Fri, Mar 18, 2022 at 02:08:16PM +, Robin Murphy wrote:
> > OK, so do we have any realistic options for identifying the correct PCI
> > devices, if USB4 PCIe adapters might be anywhere relative to their
> > associated
On Fri, Mar 18, 2022 at 03:51:21PM +0100, Lukas Wunner wrote:
> On Fri, Mar 18, 2022 at 02:08:16PM +, Robin Murphy wrote:
> > OK, so do we have any realistic options for identifying the correct PCI
> > devices, if USB4 PCIe adapters might be anywhere relative to their
> > associated NHI? Short
On Fri, Mar 18, 2022 at 02:08:16PM +, Robin Murphy wrote:
> OK, so do we have any realistic options for identifying the correct PCI
> devices, if USB4 PCIe adapters might be anywhere relative to their
> associated NHI? Short of maintaining a list of known IDs, the only thought I
> have left is
On Fri, Mar 18, 2022 at 02:08:16PM +, Robin Murphy wrote:
> On 2022-03-18 13:25, mika.westerb...@linux.intel.com wrote:
> > Hi Robin,
> >
> > On Fri, Mar 18, 2022 at 12:01:42PM +, Robin Murphy wrote:
> > > > This adds quite a lot code and complexity, and honestly I would like to
> > > >
[Public]
> -Original Message-
> From: Robin Murphy
> Sent: Friday, March 18, 2022 09:08
> To: mika.westerb...@linux.intel.com
> Cc: Limonciello, Mario ;
> andreas.noe...@gmail.com; michael.ja...@intel.com;
> yehezkel...@gmail.com; linux-...@vger.kernel.org; linux-
>
On Fri, Mar 18, 2022 at 02:23:57AM +, Tian, Kevin wrote:
> Yes, that is another major part work besides the iommufd work. And
> it is not compatible with KVM features which rely on the dynamic
> manner of EPT. Though It is a bit questionable whether it's worthy of
> doing so just for saving
On 2022-03-18 13:25, mika.westerb...@linux.intel.com wrote:
Hi Robin,
On Fri, Mar 18, 2022 at 12:01:42PM +, Robin Murphy wrote:
This adds quite a lot code and complexity, and honestly I would like to
keep it as simple as possible (and this is not enough because we need to
make sure the
On Fri, Mar 18, 2022 at 08:01:04PM +0800, Lu Baolu wrote:
> On 2022/3/15 19:49, Tian, Kevin wrote:
> > > From: Jean-Philippe Brucker
> > > Sent: Tuesday, March 15, 2022 7:27 PM
> > >
> > > On Mon, Mar 14, 2022 at 10:07:06PM -0700, Jacob Pan wrote:
> > > > From: Lu Baolu
> > > >
> > > > An IOMMU
On Fri, Mar 18, 2022 at 07:52:33PM +0800, Lu Baolu wrote:
> On 2022/3/15 13:07, Jacob Pan wrote:
> > From: Lu Baolu
> >
> > An IOMMU domain represents an address space which can be attached by
> > devices that perform DMA within a domain. However, for platforms with
> > PASID capability the
On Fri, Mar 18, 2022 at 05:47:23AM +, Tian, Kevin wrote:
> may remember more detail here) and we didn't hear strong interest
> from customer on it. So this is just FYI for theoretical possibility and
> I'm fine with even disallowing it before those issues are resolved.
I didn't mean
On Fri, Mar 18, 2022 at 07:01:19AM +, Tian, Kevin wrote:
> > From: Jason Gunthorpe
> > Sent: Tuesday, March 15, 2022 10:55 PM
> >
> > The first level iommu_domain has the 'type1' map and unmap and pins
> > the pages. This is the 1:1 map with the GPA and ends up pinning all
> > guest memory
Hi Robin,
On Fri, Mar 18, 2022 at 12:01:42PM +, Robin Murphy wrote:
> > This adds quite a lot code and complexity, and honestly I would like to
> > keep it as simple as possible (and this is not enough because we need to
> > make sure the DMAR bit is there so that none of the possible
On 2022/3/15 13:07, Jacob Pan wrote:
DMA mapping API is the de facto standard for in-kernel DMA. It operates
on a per device/RID basis which is not PASID-aware.
Some modern devices such as Intel Data Streaming Accelerator, PASID is
required for certain work submissions. To allow such devices
On 2022-03-18 11:38, mika.westerb...@linux.intel.com wrote:
Hi Mario,
On Thu, Mar 17, 2022 at 08:36:13PM +, Limonciello, Mario wrote:
Here is a proposal on top of what you did for this.
The idea being check the ports right when the links are made if they exist
(all the new USB4 stuff) and
On 2022/3/15 19:49, Tian, Kevin wrote:
From: Jean-Philippe Brucker
Sent: Tuesday, March 15, 2022 7:27 PM
On Mon, Mar 14, 2022 at 10:07:06PM -0700, Jacob Pan wrote:
From: Lu Baolu
An IOMMU domain represents an address space which can be attached by
devices that perform DMA within a domain.
On 2022-03-18 06:44, Mika Westerberg wrote:
Hi Robin,
Thanks for working on this!
On Thu, Mar 17, 2022 at 04:17:07PM +, Robin Murphy wrote:
Between me trying to get rid of iommu_present() and Mario wanting to
support the AMD equivalent of DMAR_PLATFORM_OPT_IN, scrutiny has shown
that the
On 2022/3/15 13:07, Jacob Pan wrote:
From: Lu Baolu
An IOMMU domain represents an address space which can be attached by
devices that perform DMA within a domain. However, for platforms with
PASID capability the domain attachment needs be handled at device+PASID
level. There can be multiple
Hi Mario,
On Thu, Mar 17, 2022 at 08:36:13PM +, Limonciello, Mario wrote:
> Here is a proposal on top of what you did for this.
> The idea being check the ports right when the links are made if they exist
> (all the new USB4 stuff) and then check all siblings on TBT3 stuff.
>
> diff --git
On 2022-03-17 19:13, Michael Kelley (LINUX) wrote:
From: Robin Murphy Sent: Thursday, March 17, 2022 10:20
AM
On 2022-03-17 16:25, Michael Kelley via iommu wrote:
Add a wrapper function to set dma_coherent, avoiding the need for
complex #ifdef's when setting it in architecture independent
On 2022-03-18 05:12, Michael Kelley (LINUX) wrote:
From: Robin Murphy Sent: Thursday, March 17, 2022 10:15
AM
On 2022-03-17 16:25, Michael Kelley via iommu wrote:
PCI pass-thru devices in a Hyper-V VM are represented as a VMBus
device and as a PCI device. The coherence of the VMbus device
> From: David Stevens
> Sent: Wednesday, March 16, 2022 1:07 PM
>
> From: David Stevens
>
> Fall back to domain selective flush if the target address is not aligned
> to the mask being used for invalidation. This is necessary because page
using domain selective flush is a bit conservative.
> From: Jason Gunthorpe
> Sent: Tuesday, March 15, 2022 10:55 PM
>
> The first level iommu_domain has the 'type1' map and unmap and pins
> the pages. This is the 1:1 map with the GPA and ends up pinning all
> guest memory because the point is you don't want to take a memory pin
> on your
Hi Robin,
Thanks for working on this!
On Thu, Mar 17, 2022 at 04:17:07PM +, Robin Murphy wrote:
> Between me trying to get rid of iommu_present() and Mario wanting to
> support the AMD equivalent of DMAR_PLATFORM_OPT_IN, scrutiny has shown
> that the iommu_dma_protection attribute is being
> From: Jacob Pan
> Sent: Tuesday, March 15, 2022 1:07 PM
The coverletter is [0/8] but here you actually have the 9th patch...
>
> From: Dave Jiang
>
> The idxd driver always gated the pasid enabling under a single knob and
> this assumption is incorrect. The pasid used for kernel operation
> From: Jacob Pan
> Sent: Tuesday, March 15, 2022 1:07 PM
>
> In-kernel DMA with PASID should use DMA API now, remove supervisor
> PASID
> SVA support. Remove special cases in bind mm and page request service.
>
> Signed-off-by: Jacob Pan
so you removed all the references to
> From: Jacob Pan
> Sent: Tuesday, March 15, 2022 1:07 PM
>
> The current in-kernel supervisor PASID support is based on the SVM/SVA
> machinery in SVA lib. The binding between a kernel PASID and kernel
> mapping has many flaws. See discussions in the link below.
>
> This patch enables
> -Original Message-
> From: iommu On Behalf Of
> David Stevens
> Sent: Wednesday, March 16, 2022 1:07 PM
> To: Lu Baolu
> Cc: iommu@lists.linux-foundation.org; linux-ker...@vger.kernel.org; David
> Stevens
> Subject: [PATCH] iommu/vt-d: check alignment before using psi
>
> From:
49 matches
Mail list logo
