On Wed, Sep 09, 2020 at 10:17:35PM -0400, Jason Wang wrote:
>
>
> - Original Message -
> > Hi Jason
> >
> > On Wed, Sep 09, 2020 at 04:34:32PM +0800, Jason Wang wrote:
> > > Commit 61363c1474b1 ("iommu/vt-d: Enable ATS only if the device uses
> > > page aligned address.") disables ATS
On Thu, Sep 10, 2020 at 11:13:51AM +0200, Christoph Hellwig wrote:
> On Thu, Sep 10, 2020 at 09:53:51AM +0200, Greg KH wrote:
> > > /*
> > >* Please refer to usb_alloc_dev() to see why we set
> > > - * dma_mask and dma_pfn_offset.
> > > + * dma_mask and
After commit 26e495f34107 ("iommu/amd: Restore IRTE.RemapEn bit after
programming IRTE"), smatch warns:
drivers/iommu/amd/iommu.c:3870 amd_iommu_deactivate_guest_mode()
warn: variable dereferenced before check 'entry' (see line 3867)
Fix this by moving the @valid assignment to
On 2020-09-10 06:40, Christoph Hellwig wrote:
Move the helpers to translate to and from direct mapping DMA addresses
to dma-direct.h. This not only is the most logical place, but the new
placement also avoids dependency loops with pending commits.
For the straightforward move as it should be,
On Tue, 1 Sep 2020 19:08:44 +0200
Auger Eric wrote:
> Hi Jacob,
> On 8/22/20 6:35 AM, Jacob Pan wrote:
> > IOASID core maintains the guest-host mapping in the form of SPID and
> > IOASID. This patch assigns the guest PASID (if valid) as SPID while
> > binding guest page table with a host PASID.
Hello Bjorn,
On Mon, Aug 17, 2020 at 3:50 PM Rajat Jain wrote:
>
> Hello Bjorn,
>
>
> On Sat, Aug 1, 2020 at 5:30 PM Rajat Jain wrote:
> >
> > Hi Bjorn,
> >
> >
> > On Tue, Jul 14, 2020 at 1:24 PM Rajat Jain wrote:
> > >
> > > On Tue, Jul 14, 2020 at 1:15 PM Rajat Jain wrote:
> > > >
> > > >
On Fri, Sep 4, 2020 at 8:56 AM Bjorn Andersson
wrote:
>
> Based on previous attempts and discussions this is the latest attempt at
> inheriting stream mappings set up by the bootloader, for e.g. boot splash or
> efifb.
>
> Per Will's request this builds on the work by Jordan and Rob for the
On Tue, 1 Sep 2020 11:34:19 +0800
Lu Baolu wrote:
> This adds two new APIs for the use cases like vfio/mdev where subdevices
> derived from physical devices are created and put in an iommu_group. The
> new IOMMU API interfaces mimic the vfio_mdev_at(de)tach_domain() directly,
> testing whether
On Tue, 1 Sep 2020 11:34:18 +0800
Lu Baolu wrote:
> In the vfio/mdev use case of aux-domain, the subdevices are created from
> the physical devices with IOMMU_DEV_FEAT_AUX enabled and the aux-domains
> are attached to the subdevices through the iommu_ops.aux_attach_dev()
> interface.
>
>
On Tue, 1 Sep 2020 11:34:22 +0800
Lu Baolu wrote:
> With subdevice information opt-in through iommu_ops.aux_at(de)tach_dev()
> interfaces, the vendor iommu driver is able to learn the knowledge about
> the relationships between the subdevices and the aux-domains. Implement
> is_aux_domain()
Thanks for catching this.
On 9/11/20 12:16 AM, Joao Martins wrote:
After commit 26e495f34107 ("iommu/amd: Restore IRTE.RemapEn bit after
programming IRTE"), smatch warns:
drivers/iommu/amd/iommu.c:3870 amd_iommu_deactivate_guest_mode()
warn: variable dereferenced before check
On Thu, 2020-09-10 at 15:21 +0100, Robin Murphy wrote:
> On 2020-09-09 21:06, Joe Perches wrote:
> > fallthrough to a separate case/default label break; isn't very readable.
> >
> > Convert pseudo-keyword fallthrough; statements to a simple break; when
> > the next label is case or default and
On 2020-09-08 17:39, Christoph Hellwig wrote:
dma_dummy_ops is only used by the ACPI code, which can't be modular.
Reviewed-by: Robin Murphy
Signed-off-by: Christoph Hellwig
---
kernel/dma/dummy.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/kernel/dma/dummy.c b/kernel/dma/dummy.c
On 2020-09-08 17:39, Christoph Hellwig wrote:
Now that the main dma mapping entry points are out of line none
of these functions can be called from modular code.
FWIW I did briefly look at how much of dma-debug we could drop from
dma-mapping.h and make entirely private to kernel/dma/, but
On Thu, Sep 10, 2020 at 12:45:09PM +0100, Robin Murphy wrote:
> FWIW I did briefly look at how much of dma-debug we could drop from
> dma-mapping.h and make entirely private to kernel/dma/, but couldn't
> convince myself that an awkward split with a few calls still needing to be
> public would
On Thu, Sep 10, 2020 at 11:17 AM Hans Verkuil wrote:
>
> On 04/09/2020 15:17, Marek Szyprowski wrote:
> > Use recently introduced common wrappers operating directly on the struct
> > sg_table objects and scatterlist page iterators to make the code a bit
> > more compact, robust, easier to follow
On 09/09/2020 22:06, Joe Perches wrote:
diff --git a/drivers/net/wireless/mediatek/mt7601u/dma.c
b/drivers/net/wireless/mediatek/mt7601u/dma.c
index 09f931d4598c..778be26d329f 100644
--- a/drivers/net/wireless/mediatek/mt7601u/dma.c
+++ b/drivers/net/wireless/mediatek/mt7601u/dma.c
@@
On 9/9/20 10:06 PM, Joe Perches wrote:
fallthrough to a separate case/default label break; isn't very readable.
Convert pseudo-keyword fallthrough; statements to a simple break; when
the next label is case or default and the only statement in the next
label block is break;
Found using:
$
On Wed, Sep 9, 2020 at 10:10 PM Joe Perches wrote:
>
> fallthrough to a separate case/default label break; isn't very readable.
>
> Convert pseudo-keyword fallthrough; statements to a simple break; when
> the next label is case or default and the only statement in the next
> label block is break;
>From IOMMU p.o.v., PASIDs allocated and managed by external components
(e.g. VFIO) will be passed in for gpasid_bind/unbind operation. IOMMU
needs some knowledge to check the PASID ownership, hence add an interface
for those components to tell the PASID owner.
In latest kernel design, PASID
Shared Virtual Addressing (SVA), a.k.a, Shared Virtual Memory (SVM) on
Intel platforms allows address space sharing between device DMA and
applications. SVA can reduce programming complexity and enhance security.
This VFIO series is intended to expose SVA usage to VMs. i.e. Sharing
guest
From: Eric Auger
The VFIO API was enhanced to support nested stage control: a bunch of
new ioctls and usage guideline.
Let's document the process to follow to set up nested mode.
Cc: Kevin Tian
CC: Jacob Pan
Cc: Alex Williamson
Cc: Eric Auger
Cc: Jean-Philippe Brucker
Cc: Joerg Roedel
This patch makes change to only supports the case where all the physical iommu
units have the same CAP/ECAP MASKS for nested translation.
Cc: Kevin Tian
CC: Jacob Pan
Cc: Alex Williamson
Cc: Eric Auger
Cc: Jean-Philippe Brucker
Cc: Joerg Roedel
Cc: Lu Baolu
Signed-off-by: Liu Yi L
IOMMUs that support nesting translation needs report the capability info
to userspace. It gives information about requirements the userspace needs
to implement plus other features characterizing the physical implementation.
This patch introduces a new IOMMU UAPI struct that gives information
This patch is to address a REVISIT. As ioasid_set is added to domain,
upper layer/VFIO can set ioasid_set to iommu driver, and track the
PASID ownership, so no need to get_task_mm() in intel_svm_bind_gpasid().
Cc: Kevin Tian
CC: Jacob Pan
Cc: Alex Williamson
Cc: Eric Auger
Cc: Jean-Philippe
When an IOMMU domain with nesting attribute is used for guest SVA, a
system-wide PASID is allocated for binding with the device and the domain.
For security reason, we need to check the PASID passed from user-space.
e.g. page table bind/unbind and PASID related cache invalidation.
Cc: Kevin Tian
This patch allows userspace to request PASID allocation/free, e.g. when
serving the request from the guest.
PASIDs that are not freed by userspace are automatically freed when the
IOASID set is destroyed when process exits.
Cc: Kevin Tian
CC: Jacob Pan
Cc: Alex Williamson
Cc: Eric Auger
Cc:
This patch exports iommu nesting capability info to user space through
VFIO. Userspace is expected to check this info for supported uAPIs (e.g.
PASID alloc/free, bind page table, and cache invalidation) and the vendor
specific format information for first level/stage page table that will be
bound
Shared Virtual Addressing (a.k.a Shared Virtual Memory) allows sharing
multiple process virtual address spaces with the device for simplified
programming model. PASID is used to tag an virtual address space in DMA
requests and to identify the related translation structure in IOMMU. When
a
This patch is added as instead of returning a boolean for DOMAIN_ATTR_NESTING,
iommu_domain_get_attr() should return an iommu_nesting_info handle. For
now, return an empty nesting info struct for now as true nesting is not
yet supported by the SMMUs.
Cc: Will Deacon
Cc: Robin Murphy
Cc: Eric
From: Yi Sun
Current interface is good enough for SVA virtualization on an assigned
physical PCI device, but when it comes to mediated devices, a physical
device may be attached with multiple aux-domains. Also, for guest unbind,
the PASID to be unbind should be allocated to the VM. This check
This patch provides an interface allowing the userspace to invalidate
IOMMU cache for first-level page table. It is required when the first
level IOMMU page table is not managed by the host kernel in the nested
translation setup.
Cc: Kevin Tian
CC: Jacob Pan
Cc: Alex Williamson
Cc: Eric Auger
This patch exposes PCIe PASID capability to guest for assigned devices.
Existing vfio_pci driver hides it from guest by setting the capability
length as 0 in pci_ext_cap_length[].
And this patch only exposes PASID capability for devices which has PCIe
PASID extended struture in its configuration
Recent years, mediated device pass-through framework (e.g. vfio-mdev)
is used to achieve flexible device sharing across domains (e.g. VMs).
Also there are hardware assisted mediated pass-through solutions from
platform vendors. e.g. Intel VT-d scalable mode which supports Intel
Scalable I/O
This patch reports nesting info when iommu_domain_get_attr() is called with
DOMAIN_ATTR_NESTING and one domain with nesting set.
Cc: Kevin Tian
CC: Jacob Pan
Cc: Alex Williamson
Cc: Eric Auger
Cc: Jean-Philippe Brucker
Cc: Joerg Roedel
Cc: Lu Baolu
Signed-off-by: Liu Yi L
Signed-off-by:
Nesting translation allows two-levels/stages page tables, with 1st level
for guest translations (e.g. GVA->GPA), 2nd level for host translations
(e.g. GPA->HPA). This patch adds interface for binding guest page tables
to a PASID. This PASID must have been allocated by the userspace before
the
Hi,
Joe Perches writes:
> drivers/usb/dwc3/core.c | 2 +-
> drivers/usb/gadget/legacy/inode.c | 2 +-
> drivers/usb/gadget/udc/pxa25x_udc.c | 4 ++--
> drivers/usb/phy/phy-fsl-usb.c |
On Wed, Sep 9, 2020 at 5:35 PM Robin Murphy wrote:
>
Hi Robin,
Thanks for review
> On 2020-09-09 06:32, Srinath Mannam wrote:
> > Fix IOVA reserve failure for memory regions listed in dma-ranges in the
> > following cases.
> >
> > - start address of memory region is 0x0.
>
> That's fair enough,
Hi Jacob,
On 9/10/20 12:58 AM, Jacob Pan wrote:
> On Tue, 1 Sep 2020 18:49:38 +0200
> Auger Eric wrote:
>
>> Hi Jacob,
>>
>> On 8/22/20 6:35 AM, Jacob Pan wrote:
>>> Relations among IOASID users largely follow a publisher-subscriber
>>> pattern. E.g. to support guest SVA on Intel Scalable I/O
Hi Jacob,
On 9/9/20 12:40 AM, Jacob Pan wrote:
> On Tue, 1 Sep 2020 17:38:44 +0200
> Auger Eric wrote:
>
>> Hi Jacob,
>> On 8/22/20 6:35 AM, Jacob Pan wrote:
>>> When an IOASID set is used for guest SVA, each VM will acquire its
>>> ioasid_set for IOASID allocations. IOASIDs within the VM must
> diff --git a/drivers/i2c/busses/i2c-i801.c b/drivers/i2c/busses/i2c-i801.c
> index e32ef3f01fe8..b13b1cbcac29 100644
> --- a/drivers/i2c/busses/i2c-i801.c
> +++ b/drivers/i2c/busses/i2c-i801.c
> @@ -1785,7 +1785,7 @@ static int i801_probe(struct pci_dev *dev, const struct
> pci_device_id *id)
On Thu, Sep 10, 2020 at 07:40:38AM +0200, Christoph Hellwig wrote:
> From: Jim Quinlan
>
> The new field 'dma_range_map' in struct device is used to facilitate the
> use of single or multiple offsets between mapping regions of cpu addrs and
> dma addrs. It subsumes the role of
Joe,
Please drop this chunk: it's a successive controller version number
which are all backward compatible with "fallthrough" on each case so
removing from this last one makes it inconsistent.
In sort: NACK for atmel-mci.
Best regards,
Nicolas
On 09/09/2020 at 22:06, Joe Perches wrote:
>
On 04/09/2020 15:17, Marek Szyprowski wrote:
> Use recently introduced common wrappers operating directly on the struct
> sg_table objects and scatterlist page iterators to make the code a bit
> more compact, robust, easier to follow and copy/paste safe.
>
> No functional change, because the code
On 04/09/2020 15:17, Marek Szyprowski wrote:
> The Documentation/DMA-API-HOWTO.txt states that dma_map_sg returns the
> numer of the created entries in the DMA address space. However the
numer -> number
> subsequent calls to dma_sync_sg_for_{device,cpu} and dma_unmap_sg must be
> called with the
Em Wed, 09 Sep 2020 13:06:39 -0700
Joe Perches escreveu:
> fallthrough to a separate case/default label break; isn't very readable.
>
> Convert pseudo-keyword fallthrough; statements to a simple break; when
> the next label is case or default and the only statement in the next
> label block is
On Thu, Sep 10, 2020 at 09:53:51AM +0200, Greg KH wrote:
> > /*
> > * Please refer to usb_alloc_dev() to see why we set
> > -* dma_mask and dma_pfn_offset.
> > +* dma_mask and dma_range_map.
> > */
> > intf->dev.dma_mask =
On 2020-09-09 21:06, Joe Perches wrote:
fallthrough to a separate case/default label break; isn't very readable.
Convert pseudo-keyword fallthrough; statements to a simple break; when
the next label is case or default and the only statement in the next
label block is break;
Found using:
$
On 2020-09-08 17:47, Christoph Hellwig wrote:
Driver that select DMA_OPS need to depend on HAS_DMA support to
work. The vop driver was missing that dependency, so add it, and also
add a nother depends in DMA_OPS itself. That won't fix the issue due
to how the Kconfig dependencies work, but at
On 2020-09-08 17:47, Christoph Hellwig wrote:
Replace the currently open code copy.
Reviewed-by: Robin Murphy
Signed-off-by: Christoph Hellwig
---
kernel/dma/direct.c | 5 +
1 file changed, 1 insertion(+), 4 deletions(-)
diff --git a/kernel/dma/direct.c b/kernel/dma/direct.c
index
On Wed, 9 Sep 2020 at 13:56, Tvrtko Ursulin
wrote:
>
>
> On 09/09/2020 10:16, Tvrtko Ursulin wrote:
> > On 08/09/2020 23:43, Tom Murphy wrote:
> >> On Tue, 8 Sep 2020 at 16:56, Tvrtko Ursulin
> >> wrote:
> >>> On 08/09/2020 16:44, Logan Gunthorpe wrote:
> On 2020-09-08 9:28 a.m., Tvrtko
On 2020-09-08 17:47, Christoph Hellwig wrote:
Move the detailed gfp_t setup from __dma_direct_alloc_pages into the
caller to clean things up a little.
Other than a mild nitpick that it might be nicer to spend one extra line
to keep both gfp adjustments next to each other,
Reviewed-by: Robin
On 2020-09-08 17:47, Christoph Hellwig wrote:
The __phys_to_dma vs phys_to_dma distinction isn't exactly obvious. Try
to improve the situation by renaming __phys_to_dma to
phys_to_dma_unencryped, and not forcing architectures that want to
override phys_to_dma to actually provide __phys_to_dma.
On 2020-09-08 17:47, Christoph Hellwig wrote:
Add a new file that contains helpera for misc DMA ops, which is only
The Latin plural of the singular "helperum", I guess? :P
built when CONFIG_DMA_OPS is set.
Reviewed-by: Robin Murphy
Signed-off-by: Christoph Hellwig
---
On Thu, 10 Sep 2020 at 14:33, Tom Murphy wrote:
>
> On Wed, 9 Sep 2020 at 13:56, Tvrtko Ursulin
> wrote:
> >
> >
> > On 09/09/2020 10:16, Tvrtko Ursulin wrote:
> > > On 08/09/2020 23:43, Tom Murphy wrote:
> > >> On Tue, 8 Sep 2020 at 16:56, Tvrtko Ursulin
> > >> wrote:
> > >>> On 08/09/2020
On 2020-09-08 17:47, Christoph Hellwig wrote:
dma_declare_coherent_memory should not be in a DMA API guide aimed
at driver writers (that is consumers of the API). Move it to a comment
near the function instead.
I still think there might be an occasional valid use for device-local
memory
init_iova_flush_queue can fail if we run out of memory. Fall back to noflush
queue if it fails.
Signed-off-by: Tom Murphy
---
drivers/iommu/dma-iommu.c | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/drivers/iommu/dma-iommu.c b/drivers/iommu/dma-iommu.c
index
On 2020-09-08 17:47, Christoph Hellwig wrote:
Just merge these helpers into the main dma_direct_{alloc,free} routines,
as the additional checks are always false for the two callers.
Reviewed-by: Robin Murphy
Signed-off-by: Christoph Hellwig
---
arch/x86/kernel/amd_gart_64.c | 6 +++---
On 2020-09-08 17:47, Christoph Hellwig wrote:
There is no harm in just always clearing the SME encryption bit, while
significantly simplifying the interface.
After a 10-minute diversion into "but hang on, force_dma_unencrypted()
is meaningful on PPC and S390 too..." before realising that it
59 matches
Mail list logo
