Hi Bjorn,
On 9/4/21 3:37 AM, Bjorn Helgaas wrote:
From: Bjorn Helgaas
719a19335692 ("iommu/vt-d: Tweak the description of a DMA fault") changed
the DMA fault reason from hex to decimal. It also added "0x" prefixes to
the PCI bus/device, e.g.,
- DMAR: [INTR-REMAP] Request device [00:00.5]
From: Bjorn Helgaas
719a19335692 ("iommu/vt-d: Tweak the description of a DMA fault") changed
the DMA fault reason from hex to decimal. It also added "0x" prefixes to
the PCI bus/device, e.g.,
- DMAR: [INTR-REMAP] Request device [00:00.5]
+ DMAR: [INTR-REMAP] Request device [0x00:0x00.5]
Hi Joerg,
A fix is queued for v5.15. It aims to fix:
- Drop "0x" prefix from PCI bus & device addresses
Please consider it for the iommu/fix branch.
Best regards,
Lu Baolu
Bjorn Helgaas (1):
iommu/vt-d: Drop "0x" prefix from PCI bus & device addresses
drivers/iommu/intel/dmar.c | 6
Showcase a partial usage of the new PASID DMA API, it replaces SVA
lib API in terms of obtaining system PASID and addressing mode setup.
But the actual work submission is not included.
Signed-off-by: Jacob Pan
---
drivers/dma/idxd/idxd.h | 4 +++-
drivers/dma/idxd/init.c | 36
For physical address(PA) mode, PASID entry for the given supervisor
PASID will be set up for HW pass-through (PT). For IOVA mode, the
supervisor PASID entry will be configured the same as PASID 0, which is
a special PASID for DMA request w/o PASID, a.k.a.
RID2PASID. Additional IOTLB flush for the
To support KVA fast mode, the VT-d driver must support domain allocation
of IOMMU_DOMAIN_KVA type. Since all devices in fast KVA mode share the
same kernel mapping, a single KVA domain is sufficient. This global KVA
domain contains the kernel mapping, i.e. init_mm.pgd.
The programming of the KVA
This patch adds KVA map API. It enforces KVA address range checking and
other potential sanity checks. Currently, only the direct map range is
checked.
For trusted devices, this API returns immediately after the above sanity
check. For untrusted devices, this API serves as a simple wrapper around
IOASIDs associated with user processes are subject to resource
restrictions. However, in-kernel usages can target only one global
kernel virtual address mapping. Reserve a special IOASID for the devices
that perform DMA requests with PASID. This global PASID is excluded from
the IOASID allocator.
Sharing virtual addresses between DMA and CPU has many advantages. It
simplifies the programming model, enhances DMA security over physical
addresses. This patch adds KVA support for DMA IOMMU API. Strict and
fast sub-modes are supported transparently based on the device
trustfulness.
The strict
DMA-API is the standard way for device drivers to perform in-kernel
DMA requests. If security is on, isolation is enforced by the IOMMU at
requester ID (RID) granularity. With the introduction of process address
space ID (PASID), DMA security is enforced per RID+PASID
granularity. On some modern
Hi Joerg/Jason/Christoph et all,
The current in-kernel supervisor PASID support is based on the SVM/SVA
machinery in sva-lib. Kernel SVA is achieved by extending a special flag
to indicate the binding of the device and a page table should be performed
on init_mm instead of the mm of the current
On Wed, Sep 22, 2021 at 10:31:47AM +0800, Lu Baolu wrote:
> Hi Jason,
>
> On 9/22/21 12:19 AM, Jason Gunthorpe wrote:
>> On Sun, Sep 19, 2021 at 02:38:32PM +0800, Liu Yi L wrote:
>>> From: Lu Baolu
>>>
>>> This provides an interface for upper layers to get the per-device iommu
>>> attributes.
>>>
> From: Jason Gunthorpe
> Sent: Wednesday, September 22, 2021 2:15 AM
>
> On Sun, Sep 19, 2021 at 02:38:44PM +0800, Liu Yi L wrote:
> > [HACK. will fix in v2]
> >
> > There are two options to impelement vfio type1v2 mapping semantics in
> > /dev/iommu.
> >
> > One is to duplicate the related
> From: Jason Gunthorpe
> Sent: Wednesday, September 22, 2021 2:04 AM
>
> On Sun, Sep 19, 2021 at 02:38:43PM +0800, Liu Yi L wrote:
> > This patch adds interface for userspace to attach device to specified
> > IOASID.
> >
> > Note:
> > One device can only be attached to one IOASID in this
> From: Jason Gunthorpe
> Sent: Wednesday, September 22, 2021 2:02 AM
>
> > +static int ioas_check_device_compatibility(struct iommufd_ioas *ioas,
> > + struct device *dev)
> > +{
> > + bool snoop = false;
> > + u32 addr_width;
> > + int ret;
> > +
> >
> From: Jason Gunthorpe
> Sent: Wednesday, September 22, 2021 1:47 AM
>
> On Sun, Sep 19, 2021 at 02:38:40PM +0800, Liu Yi L wrote:
> > As aforementioned, userspace should check extension for what formats
> > can be specified when allocating an IOASID. This patch adds such
> > interface for
> From: Jason Gunthorpe
> Sent: Wednesday, September 22, 2021 1:45 AM
>
> On Sun, Sep 19, 2021 at 02:38:39PM +0800, Liu Yi L wrote:
> > This patch adds IOASID allocation/free interface per iommufd. When
> > allocating an IOASID, userspace is expected to specify the type and
> > format
> From: Jason Gunthorpe
> Sent: Wednesday, September 22, 2021 1:41 AM
>
> On Sun, Sep 19, 2021 at 02:38:38PM +0800, Liu Yi L wrote:
> > After a device is bound to the iommufd, userspace can use this interface
> > to query the underlying iommu capability and format info for this device.
> > Based
> From: Jason Gunthorpe
> Sent: Tuesday, September 21, 2021 9:45 PM
>
> On Sun, Sep 19, 2021 at 02:38:28PM +0800, Liu Yi L wrote:
> > Linux now includes multiple device-passthrough frameworks (e.g. VFIO
> and
> > vDPA) to manage secure device access from the userspace. One critical
> task
> > of
> From: Tian, Kevin
> Sent: Wednesday, September 22, 2021 9:07 AM
>
> > From: Jason Gunthorpe
> > Sent: Wednesday, September 22, 2021 8:55 AM
> >
> > On Tue, Sep 21, 2021 at 11:56:06PM +, Tian, Kevin wrote:
> > > > The opened atomic is aweful. A newly created fd should start in a
> > > >
Hi Jason,
On 9/22/21 12:19 AM, Jason Gunthorpe wrote:
On Sun, Sep 19, 2021 at 02:38:32PM +0800, Liu Yi L wrote:
From: Lu Baolu
This provides an interface for upper layers to get the per-device iommu
attributes.
int iommu_device_get_info(struct device *dev,
> From: Jason Gunthorpe
> Sent: Wednesday, September 22, 2021 1:10 AM
>
> On Sun, Sep 19, 2021 at 02:38:34PM +0800, Liu Yi L wrote:
> > From: Lu Baolu
> >
> > This extends iommu core to manage security context for passthrough
> > devices. Please bear a long explanation for how we reach this
> From: Jason Gunthorpe
> Sent: Tuesday, September 21, 2021 11:42 PM
>
> - Delete the iommufd_ctx->lock. Use RCU to protect load, erase/alloc does
>not need locking (order it properly too, it is in the wrong order), and
>don't check for duplicate devices or dev_cookie duplication, that
> From: Jason Gunthorpe
> Sent: Wednesday, September 22, 2021 5:59 AM
>
> On Tue, Sep 21, 2021 at 03:09:29PM -0600, Alex Williamson wrote:
>
> > the iommufd uAPI at all. Isn't part of that work to understand how KVM
> > will be told about non-coherent devices rather than "meh, skip it in the
>
> From: Alex Williamson
> Sent: Wednesday, September 22, 2021 5:09 AM
>
> On Tue, 21 Sep 2021 13:40:01 -0300
> Jason Gunthorpe wrote:
>
> > On Sun, Sep 19, 2021 at 02:38:33PM +0800, Liu Yi L wrote:
> > > This patch exposes the device-centric interface for vfio-pci devices. To
> > > be
> From: Jason Gunthorpe
> Sent: Wednesday, September 22, 2021 8:55 AM
>
> On Tue, Sep 21, 2021 at 11:56:06PM +, Tian, Kevin wrote:
> > > The opened atomic is aweful. A newly created fd should start in a
> > > state where it has a disabled fops
> > >
> > > The only thing the disabled fops can
> From: Jason Gunthorpe
> Sent: Wednesday, September 22, 2021 9:00 AM
>
> On Wed, Sep 22, 2021 at 12:54:02AM +, Tian, Kevin wrote:
> > > From: Jason Gunthorpe
> > > Sent: Wednesday, September 22, 2021 12:01 AM
> > >
> > > > One open about how to organize the device nodes under
> > >
On Wed, Sep 22, 2021 at 12:54:02AM +, Tian, Kevin wrote:
> > From: Jason Gunthorpe
> > Sent: Wednesday, September 22, 2021 12:01 AM
> >
> > > One open about how to organize the device nodes under
> > /dev/vfio/devices/.
> > > This RFC adopts a simple policy by keeping a flat layout with
> From: Jason Gunthorpe
> Sent: Wednesday, September 22, 2021 8:54 AM
>
> On Tue, Sep 21, 2021 at 11:10:15PM +, Tian, Kevin wrote:
> > > From: Jason Gunthorpe
> > > Sent: Wednesday, September 22, 2021 12:01 AM
> > >
> > > On Sun, Sep 19, 2021 at 02:38:31PM +0800, Liu Yi L wrote:
> > > >
> From: Alex Williamson
> Sent: Wednesday, September 22, 2021 3:56 AM
>
> On Sun, 19 Sep 2021 14:38:30 +0800
> Liu Yi L wrote:
>
> > This patch introduces a new interface (/dev/vfio/devices/$DEVICE) for
> > userspace to directly open a vfio device w/o relying on container/group
> >
On Tue, Sep 21, 2021 at 11:56:06PM +, Tian, Kevin wrote:
> > The opened atomic is aweful. A newly created fd should start in a
> > state where it has a disabled fops
> >
> > The only thing the disabled fops can do is register the device to the
> > iommu fd. When successfully registered the
> From: Jason Gunthorpe
> Sent: Wednesday, September 22, 2021 12:01 AM
>
> > One open about how to organize the device nodes under
> /dev/vfio/devices/.
> > This RFC adopts a simple policy by keeping a flat layout with mixed
> devname
> > from all kinds of devices. The prerequisite of this
On Tue, Sep 21, 2021 at 11:10:15PM +, Tian, Kevin wrote:
> > From: Jason Gunthorpe
> > Sent: Wednesday, September 22, 2021 12:01 AM
> >
> > On Sun, Sep 19, 2021 at 02:38:31PM +0800, Liu Yi L wrote:
> > > With /dev/vfio/devices introduced, now a vfio device driver has three
> > > options to
> From: Jason Gunthorpe
> Sent: Tuesday, September 21, 2021 11:57 PM
>
> On Sun, Sep 19, 2021 at 02:38:30PM +0800, Liu Yi L wrote:
> > This patch introduces a new interface (/dev/vfio/devices/$DEVICE) for
> > userspace to directly open a vfio device w/o relying on container/group
> >
> From: Jason Gunthorpe
> Sent: Wednesday, September 22, 2021 12:01 AM
>
> On Sun, Sep 19, 2021 at 02:38:31PM +0800, Liu Yi L wrote:
> > With /dev/vfio/devices introduced, now a vfio device driver has three
> > options to expose its device to userspace:
> >
> > a) only legacy group interface,
On Tue, Sep 21, 2021 at 03:09:29PM -0600, Alex Williamson wrote:
> the iommufd uAPI at all. Isn't part of that work to understand how KVM
> will be told about non-coherent devices rather than "meh, skip it in the
> kernel"? Also let's not forget that vfio is not only for KVM.
vfio is not only
On Tue, Sep 21, 2021 at 04:43:59PM -0500, Tom Lendacky wrote:
> On 9/21/21 4:34 PM, Kirill A. Shutemov wrote:
> > On Tue, Sep 21, 2021 at 11:27:17PM +0200, Borislav Petkov wrote:
> > > On Wed, Sep 22, 2021 at 12:20:59AM +0300, Kirill A. Shutemov wrote:
> > > > I still believe calling
On 9/21/21 4:34 PM, Kirill A. Shutemov wrote:
On Tue, Sep 21, 2021 at 11:27:17PM +0200, Borislav Petkov wrote:
On Wed, Sep 22, 2021 at 12:20:59AM +0300, Kirill A. Shutemov wrote:
I still believe calling cc_platform_has() from __startup_64() is totally
broken as it lacks proper wrapping while
On Tue, Sep 21, 2021 at 11:27:17PM +0200, Borislav Petkov wrote:
> On Wed, Sep 22, 2021 at 12:20:59AM +0300, Kirill A. Shutemov wrote:
> > I still believe calling cc_platform_has() from __startup_64() is totally
> > broken as it lacks proper wrapping while accessing global variables.
>
> Well,
On Wed, Sep 22, 2021 at 12:20:59AM +0300, Kirill A. Shutemov wrote:
> I still believe calling cc_platform_has() from __startup_64() is totally
> broken as it lacks proper wrapping while accessing global variables.
Well, one of the issues on the AMD side was using boot_cpu_data too
early and the
On Tue, Sep 21, 2021 at 07:47:15PM +0200, Borislav Petkov wrote:
> On Tue, Sep 21, 2021 at 12:04:58PM -0500, Tom Lendacky wrote:
> > Looks like instrumentation during early boot. I worked with Boris offline to
> > exclude arch/x86/kernel/cc_platform.c from some of the instrumentation and
> > that
On Tue, 21 Sep 2021 13:40:01 -0300
Jason Gunthorpe wrote:
> On Sun, Sep 19, 2021 at 02:38:33PM +0800, Liu Yi L wrote:
> > This patch exposes the device-centric interface for vfio-pci devices. To
> > be compatiable with existing users, vfio-pci exposes both legacy group
> > interface and
On Tue, 14 Sep 2021 19:36:52 +0800, Yong Wu wrote:
> Add the binding for smi-sub-common. The SMI block diagram like this:
>
> IOMMU
> | |
> smi-common
> --
> | |
> larb0 larb7 <-max is 8
>
> The smi-common connects with
On Sun, 19 Sep 2021 14:38:30 +0800
Liu Yi L wrote:
> This patch introduces a new interface (/dev/vfio/devices/$DEVICE) for
> userspace to directly open a vfio device w/o relying on container/group
> (/dev/vfio/$GROUP). Anything related to group is now hidden behind
> iommufd (more specifically
On Sun, Sep 19, 2021 at 02:38:44PM +0800, Liu Yi L wrote:
> [HACK. will fix in v2]
>
> There are two options to impelement vfio type1v2 mapping semantics in
> /dev/iommu.
>
> One is to duplicate the related code from vfio as the starting point,
> and then merge with vfio type1 at a later time.
On Sun, Sep 19, 2021 at 02:38:43PM +0800, Liu Yi L wrote:
> This patch adds interface for userspace to attach device to specified
> IOASID.
>
> Note:
> One device can only be attached to one IOASID in this version. This is
> on par with what vfio provides today. In the future this restriction can
On Sun, Sep 19, 2021 at 02:38:42PM +0800, Liu Yi L wrote:
> An I/O address space takes effect in the iommu only after it's attached
> by a device. This patch provides iommufd_device_[de/at]tach_ioasid()
> helpers for this purpose. One device can be only attached to one ioasid
> at this point, but
On Tue, Sep 21, 2021 at 12:04:58PM -0500, Tom Lendacky wrote:
> Looks like instrumentation during early boot. I worked with Boris offline to
> exclude arch/x86/kernel/cc_platform.c from some of the instrumentation and
> that allowed an allyesconfig to boot.
And here's the lineup I have so far,
On Sun, Sep 19, 2021 at 02:38:40PM +0800, Liu Yi L wrote:
> As aforementioned, userspace should check extension for what formats
> can be specified when allocating an IOASID. This patch adds such
> interface for userspace. In this RFC, iommufd reports EXT_MAP_TYPE1V2
> support and no no-snoop
On Sun, Sep 19, 2021 at 02:38:39PM +0800, Liu Yi L wrote:
> This patch adds IOASID allocation/free interface per iommufd. When
> allocating an IOASID, userspace is expected to specify the type and
> format information for the target I/O page table.
>
> This RFC supports only one type
On Sun, Sep 19, 2021 at 02:38:38PM +0800, Liu Yi L wrote:
> After a device is bound to the iommufd, userspace can use this interface
> to query the underlying iommu capability and format info for this device.
> Based on this information the user then creates I/O address space in a
> compatible
On Sun, Sep 19, 2021 at 02:38:36PM +0800, Liu Yi L wrote:
> This patch adds VFIO_DEVICE_BIND_IOMMUFD for userspace to bind the vfio
> device to an iommufd. No VFIO_DEVICE_UNBIND_IOMMUFD interface is provided
> because it's implicitly done when the device fd is closed.
>
> In concept a vfio device
On Sun, Sep 19, 2021 at 02:38:35PM +0800, Liu Yi L wrote:
> +/*
> + * A iommufd_device object represents the binding relationship
> + * between iommufd and device. It is created per a successful
> + * binding request from device driver. The bound device must be
> + * a physical device so far.
Hi John,
> But is the polarity really correct? That is, if we don't have space,
> then exit with success (the function to check for space).
You are absolutely correct, this is a mistake that I made as I was resolving
conflicts while porting this patch to iommu/next from 5.4 where I implemented
On Sun, Sep 19, 2021 at 02:38:34PM +0800, Liu Yi L wrote:
> From: Lu Baolu
>
> This extends iommu core to manage security context for passthrough
> devices. Please bear a long explanation for how we reach this design
> instead of managing it solely in iommufd like what vfio does today.
>
>
On 9/20/21 2:23 PM, Kirill A. Shutemov wrote:
On Wed, Sep 08, 2021 at 05:58:36PM -0500, Tom Lendacky wrote:
diff --git a/arch/x86/mm/mem_encrypt_identity.c
b/arch/x86/mm/mem_encrypt_identity.c
index 470b20208430..eff4d19f9cb4 100644
--- a/arch/x86/mm/mem_encrypt_identity.c
+++
On Sun, Sep 19, 2021 at 02:38:33PM +0800, Liu Yi L wrote:
> This patch exposes the device-centric interface for vfio-pci devices. To
> be compatiable with existing users, vfio-pci exposes both legacy group
> interface and device-centric interface.
>
> As explained in last patch, this change
On Sun, Sep 19, 2021 at 02:38:32PM +0800, Liu Yi L wrote:
> From: Lu Baolu
>
> This provides an interface for upper layers to get the per-device iommu
> attributes.
>
> int iommu_device_get_info(struct device *dev,
> enum iommu_devattr attr, void *data);
Can't
On 21/09/2021 12:43, Fernand Sieber wrote:
do {
I didn't follow the full logic of this change yet ...
llq->val = READ_ONCE(cmdq->q.llq.val);
- if (!queue_full(llq))
+ if (!queue_has_space(llq, n))
But is the polarity really correct? That
On Fri, Apr 23, 2021 at 03:21:46PM +0530, Vivek Gautam wrote:
> Once the page faults are handled, the response has to be sent to
> virtio-iommu backend, from where it can be sent to the host to
> prepare the response to a generated io page fault by the device.
> Add a new virt-queue request type
On Fri, Apr 23, 2021 at 03:21:45PM +0530, Vivek Gautam wrote:
> SVA bind and unbind implementations will allow to prepare translation
> context with CPU page tables that can be programmed into host iommu
> hardware to realize shared address space utilization between the CPU
> and virtualized
On Fri, Apr 23, 2021 at 03:21:44PM +0530, Vivek Gautam wrote:
> Implementing the alloc_shared_cd and free_shared_cd in cd-lib, and
> start using them for arm-smmu-v3-sva implementation.
>
> Signed-off-by: Vivek Gautam
> ---
> .../arm/arm-smmu-v3/arm-smmu-v3-cd-lib.c | 71
>
On Fri, Apr 23, 2021 at 03:21:41PM +0530, Vivek Gautam wrote:
> Add a feature flag to virtio iommu for Shared virtual addressing
> (SVA). This feature would indicate the availablily path for handling
> device page faults, and the provision for sending page response.
In this case the feature
On Fri, Apr 23, 2021 at 03:21:39PM +0530, Vivek Gautam wrote:
> Redirect the incoming page faults to the registered fault handler
> that can take the fault information such as, pasid, page request
> group-id, address and pasid flags.
>
> Signed-off-by: Vivek Gautam
> ---
>
On Sun, Sep 19, 2021 at 02:38:31PM +0800, Liu Yi L wrote:
> With /dev/vfio/devices introduced, now a vfio device driver has three
> options to expose its device to userspace:
>
> a) only legacy group interface, for devices which haven't been moved to
> iommufd (e.g. platform devices, sw
On Fri, Apr 23, 2021 at 03:21:38PM +0530, Vivek Gautam wrote:
> Keeping a record of list of endpoints that are served by the virtio-iommu
> device would help in redirecting the requests of page faults to the
> correct endpoint device to handle such requests.
>
> Signed-off-by: Vivek Gautam
> ---
Hi Vivek,
Thanks a lot for your work on this
On Fri, Apr 23, 2021 at 03:21:37PM +0530, Vivek Gautam wrote:
> Add fault information for group-id and necessary flags for page
> request faults that can be handled by page fault handler in
> virtio-iommu driver.
>
> Signed-off-by: Vivek Gautam
>
On Sun, Sep 19, 2021 at 02:38:30PM +0800, Liu Yi L wrote:
> This patch introduces a new interface (/dev/vfio/devices/$DEVICE) for
> userspace to directly open a vfio device w/o relying on container/group
> (/dev/vfio/$GROUP). Anything related to group is now hidden behind
> iommufd (more
On Tue, 21 Sep 2021 16:39:34 +0100,
Sven Peter wrote:
>
> apple_dart_tlb_flush_{all,walk} expect to get a struct apple_dart_domain
> but instead get a struct iommu_domain right now. This breaks those two
> functions and can lead to kernel panics like the one below.
> DART can only invalidate the
On Sun, Sep 19, 2021 at 02:38:29PM +0800, Liu Yi L wrote:
> /dev/iommu aims to provide a unified interface for managing I/O address
> spaces for devices assigned to userspace. This patch adds the initial
> framework to create a /dev/iommu node. Each open of this node returns an
> iommufd. And this
apple_dart_tlb_flush_{all,walk} expect to get a struct apple_dart_domain
but instead get a struct iommu_domain right now. This breaks those two
functions and can lead to kernel panics like the one below.
DART can only invalidate the entire TLB and apple_dart_iotlb_sync will
already flush
Hi Robin,
>> I use Xen PV display. In my case, PV display backend(Dom0) allocates
>> contiguous buffer via DMA-API to
>> to implement zero-copy between Dom0 and DomU.
>>
> Well, something's gone badly wrong there - if you have to shadow the
> entire thing in a bounce buffer to import it then it's
On Sun, Sep 19, 2021 at 02:38:28PM +0800, Liu Yi L wrote:
> Linux now includes multiple device-passthrough frameworks (e.g. VFIO and
> vDPA) to manage secure device access from the userspace. One critical task
> of those frameworks is to put the assigned device in a secure, IOMMU-
> protected
When a thread sends commands to the SMMU, it needs to allocate some
space to write its commands in a ring buffer.
The allocation algorithms works as follows: until enough free spaced is
available in the queue, repeat the following outer loop. First, try to
acquire an exclusive lock to read the
On 02/08/2021 17:16, Robin Murphy wrote:
Also fix up all users to set this value (at 0, meaning use default).
Wrap that in init_iova_domain_defaults() to avoid the mysterious 0?
Sure, I can do something like that. I actually did have separate along
those lines in v3 before I decided to
75 matches
Mail list logo
