The following changes since commit 0e2adab6cf285c41e825b6c74a3aa61324d1132c:
Merge tag 'arm64-fixes' of
git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux (2019-10-17 17:00:14
-0700)
are available in the Git repository at:
git://git.infradead.org/users/hch/dma-mapping.git tags/dma-m
The definition makes very little sense. Any without a user in the
same series it is a complete no-go anyway.
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
Hi,
On 10/25/19 3:27 PM, Tian, Kevin wrote:
From: Jacob Pan [mailto:jacob.jun@linux.intel.com]
Sent: Friday, October 25, 2019 3:55 AM
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 add
Hi,
On 10/25/19 3:55 AM, Jacob Pan wrote:
When Shared Virtual Memory is exposed to a guest via vIOMMU, scalable
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: Jac
Hi,
On 10/25/19 3:55 AM, Jacob Pan wrote:
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 wil
Hi,
On 10/25/19 3:55 AM, Jacob Pan wrote:
Use combined macros for_each_svm_dev() to simplify SVM device iteration
and error checking.
Suggested-by: Andy Shevchenko
Signed-off-by: Jacob Pan
Reviewed-by: Eric Auger
---
drivers/iommu/intel-svm.c | 89 ++
Currently, IOMMU_QCOM_SYS_CACHE exists to allow non-coherent
I/O masters on Qualcomm SoCs to upgrade to caching their
buffers in the outer-level/system cache on these platforms.
However, these masters are limited to managing the mapping
of these buffers themselves through the IOMMU framework,
as op
Although it's conceptually nice for the io_pgtable_cfg to provide a
standard VMSA TCR value, the reality is that no VMSA-compliant IOMMU
looks exactly like an Arm CPU, and they all have various other TCR
controls which io-pgtable can't be expected to understand. Thus since
there is an expectation t
Now that we can correctly extract top-level indices without relying on
the remaining upper bits being zero, the only remaining impediments to
using a given table for TTBR1 are the address validation on map/unmap
and the awkward TCR translation granule format. Add a quirk so that we
can do the right
TTBR1 values have so far been redundant since no users implement any
support for split address spaces. Crucially, though, one of the main
reasons for wanting to do so is to be able to manage each half entirely
independently, e.g. context-switching one set of mappings without
disturbing the other. T
The selftests run as an initcall, but the annotation of the various
callbacks and data seems to be somewhat arbitrary. Add it consistently
for everything related to the selftests.
Signed-off-by: Robin Murphy
---
drivers/iommu/io-pgtable-arm-v7s.c | 15 ---
drivers/iommu/io-pgtable-ar
We use data->pgd_size directly for the one-off allocation and freeing of
the top-level table, but otherwise it serves for ARM_LPAE_PGD_IDX() to
repeatedly re-calculate the effective number of top-level address bits
it represents. Flip this around so we store the form we most commonly
need, and deri
Beyond a couple of allocation-time calculations, data->levels is only
ever used to derive the start level. Storing the start level directly
leads to a small reduction in object code, which should help eke out a
little more efficiency, and slightly more readable source to boot.
Signed-off-by: Robin
Between VMSAv8-64 and the various 32-bit formats, there is either one
64-bit MAIR or a pair of 32-bit MAIR0/MAIR1 or NMRR/PMRR registers.
As such, keeping two 64-bit values in io_pgtable_cfg has always been
overkill.
Signed-off-by: Robin Murphy
---
drivers/iommu/arm-smmu-v3.c| 2 +-
drivers/
The nature of the LPAE format means that data->pg_shift is always
redundant with data->bits_per_level, since they represent the size of a
page and the number of PTEs per page respectively, and the size of a PTE
is constant. Thus it works out more efficient to only store the latter,
and derive the f
We're merely checking that the relevant upper bits of each address
are all zero, so there are cheaper ways to achieve that.
Signed-off-by: Robin Murphy
---
drivers/iommu/io-pgtable-arm.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/iommu/io-pgtable-arm.c b/dri
It makes little sense to only validate the requested size after we think
we've found a matching block size - making the check up-front is simple,
and far more logical than waiting to walk off the bottom of the table to
infer that we must have been passed a bogus size to start with.
We're missing a
Hi all,
Since the flawed first attempt, I've reworked things with an abstracted
TCR and an explicit TTBR1 quirk. I originally envisaged the need to pass
the quirk all the way down to the TLBI calls, hence getting diverted
into trying to make the parameter passing less cluttered in general, but
in
Hi Kevin,
On Fri, 25 Oct 2019 07:19:26 +
"Tian, Kevin" wrote:
> > From: Jacob Pan [mailto:jacob.jun@linux.intel.com]
> > Sent: Friday, October 25, 2019 3:55 AM
> >
> > When supporting guest SVA with emulated IOMMU, the guest PASID
> > table is shadowed in VMM. Updates to guest vIOMMU P
On Fri, 25 Oct 2019 23:04:48 +0800
Lu Baolu wrote:
> Hi,
>
> On 10/25/19 3:55 AM, Jacob Pan wrote:
> > 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 lev
> From: Lu Baolu [mailto:baolu...@linux.intel.com]
> Sent: Friday, October 25, 2019 10:39 PM
>
> Hi,
>
> On 10/25/19 2:40 PM, Tian, Kevin wrote:
> ioasid_register_allocator(&iommu->pasid_allocator);
> +if (ret) {
> +pr_warn("C
Hi,
On 10/25/19 3:55 AM, Jacob Pan wrote:
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 virtualizati
Hi,
On 10/25/19 2:40 PM, Tian, Kevin wrote:
ioasid_register_allocator(&iommu->pasid_allocator);
+ if (ret) {
+ pr_warn("Custom PASID allocator
registeration failed\n");
+ /*
+* Disab
Hi Kevin,
> From: Tian, Kevin
> Sent: Friday, October 25, 2019 5:14 PM
> To: Liu, Yi L ; alex.william...@redhat.com;
> Subject: RE: [RFC v2 1/3] vfio: VFIO_IOMMU_CACHE_INVALIDATE
>
> > From: Liu, Yi L
> > Sent: Thursday, October 24, 2019 8:26 PM
> >
> > From: Liu Yi L
> >
> > When the guest "own
Hi Kevin,
> From: Tian, Kevin
> Sent: Friday, October 25, 2019 4:59 PM
> To: Liu, Yi L ; alex.william...@redhat.com;
> Subject: RE: [RFC v2 0/3] vfio: support Shared Virtual Addressing
>
> > From: Liu Yi L
> > Sent: Thursday, October 24, 2019 8:26 PM
> >
> > Shared virtual address (SVA), a.k.a, S
Hi Kevin,
> From: Tian, Kevin
> Sent: Friday, October 25, 2019 6:06 PM
> To: Liu, Yi L ; alex.william...@redhat.com;
> Subject: RE: [RFC v2 2/3] vfio/type1: VFIO_IOMMU_PASID_REQUEST(alloc/free)
>
> > From: Liu Yi L
> > Sent: Thursday, October 24, 2019 8:26 PM
> >
> > This patch adds VFIO_IOMMU_PA
> From: Liu Yi L
> Sent: Thursday, October 24, 2019 8:26 PM
>
> This patch adds VFIO_IOMMU_PASID_REQUEST ioctl which aims
> to passdown PASID allocation/free request from the virtual
> iommu. This is required to get PASID managed in system-wide.
>
> Cc: Kevin Tian
> Signed-off-by: Liu Yi L
> Si
> From: Liu, Yi L
> Sent: Thursday, October 24, 2019 8:26 PM
>
> From: Liu Yi L
>
> When the guest "owns" the stage 1 translation structures, the host
> IOMMU driver has no knowledge of caching structure updates unless
> the guest invalidation requests are trapped and passed down to the
> host.
> From: Liu Yi L
> Sent: Thursday, October 24, 2019 8:26 PM
>
> 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 in
Thanks for the review. Please see my response inline.
> > + select DMA_CMA
>
> Thіs needs to be
>
> select DMA_CMA if HAVE_DMA_CONTIGUOUS
>
> > +#include
>
> > + /* Allocate from CMA */
> > + // request_pages = (request_size >> PAGE_SHIFT) + 1;
> > + request_pages = (round_up(re
> From: Jacob Pan [mailto:jacob.jun@linux.intel.com]
> Sent: Friday, October 25, 2019 3:55 AM
>
> 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
> From: Jacob Pan [mailto:jacob.jun@linux.intel.com]
> Sent: Friday, October 25, 2019 3:55 AM
>
> When Shared Virtual Memory is exposed to a guest via vIOMMU, scalable
> IOTLB invalidation may be passed down from outside IOMMU subsystems.
from outside of host IOMMU subsystem
> This patch add
> From: Jacob Pan [mailto:jacob.jun@linux.intel.com]
> Sent: Friday, October 25, 2019 3:55 AM
>
> 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
> From: Jacob Pan [mailto:jacob.jun@linux.intel.com]
> Sent: Friday, October 25, 2019 3:55 AM
>
> 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)
34 matches
Mail list logo
