I think we agree that the parameter should be a u64 instead, and either
Nicolas or Robin (sorry, fading memory) promised to send me a patch for
that.
___
iommu mailing list
iommu@lists.linux-foundation.org
On 2019/12/11 上午8:09, kbuild test robot wrote:
Hi Zhangfei,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on cryptodev/master]
[also build test ERROR on crypto/master char-misc/char-misc-testing v5.5-rc1
next-20191210]
[if your patch is applied to the wrong git
Add nodes for M4U, smi-common, and smi-larbs.
Signed-off-by: Yong Wu
---
change notes:
v2: Rebase on v5.5-rc1 and power_domain nodes[1].
[1] https://lore.kernel.org/patchwork/patch/1164746/
v1: https://lore.kernel.org/patchwork/patch/1054099/
---
arch/arm64/boot/dts/mediatek/mt8183.dtsi |
Intel VT-d in scalable mode supports two types of page tables
for DMA translation: the first level page table and the second
level page table. The first level page table uses the same
format as the CPU page table, while the second level page table
keeps compatible with previous formats. The
When software has changed first-level tables, it should invalidate
the affected IOTLB and the paging-structure-caches using the PASID-
based-IOTLB Invalidate Descriptor defined in spec 6.5.2.4.
Signed-off-by: Lu Baolu
---
drivers/iommu/dmar.c| 41 ++
This adds the Intel VT-d specific callback of setting
DOMAIN_ATTR_NESTING domain attribution. It is necessary
to let the VT-d driver know that the domain represents
a virtual machine which requires the IOMMU hardware to
support nested translation mode. Return success if the
IOMMU hardware suports
After we make all map/unmap paths support first level page table.
Let's turn it on if hardware supports scalable mode.
Signed-off-by: Lu Baolu
---
drivers/iommu/intel-iommu.c | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/iommu/intel-iommu.c
Intel VT-d in scalable mode supports two types of page tables for
IOVA translation: first level and second level. The IOMMU driver
can choose one from both for IOVA translation according to the use
case. This sets up the pasid entry if a domain is selected to use
the first-level page table for
Current intel_pasid_setup_first_level() use 5-level paging for
first level translation if CPUs use 5-level paging mode too.
This makes sense for SVA usages since the page table is shared
between CPUs and IOMMUs. But it makes no sense if we only want
to use first level for IOVA translation. Add
This checks whether a domain should use the first level page
table for map/unmap and marks it in the domain structure.
Signed-off-by: Lu Baolu
---
drivers/iommu/intel-iommu.c | 39 +
1 file changed, 39 insertions(+)
diff --git a/drivers/iommu/intel-iommu.c
Hi Jacob,
On 12/3/19 7:27 AM, Jacob Pan wrote:
On Thu, 28 Nov 2019 10:25:47 +0800
Lu Baolu wrote:
This adds functions to manipulate first level page tables
which could be used by a scalale mode capable IOMMU unit.
FL and SL page tables are very similar, and I presume we are not using
all
Current map_sg stores trace message in a coarse manner. This
extends it so that more detailed messages could be traced.
The map_sg trace message looks like:
map_sg: dev=:00:17.0 [1/9] dev_addr=0xf8f9 phys_addr=0x158051000
size=4096
map_sg: dev=:00:17.0 [2/9] dev_addr=0xf8f91000
If the default DMA domain of a group doesn't fit a device, it
will still sit in the group but use a private identity domain.
When map/unmap/iova_to_phys come through iommu API, the driver
should still serve them, otherwise, other devices in the same
group will be impacted. Since identity domain
Hi,
On 12/11/19 2:56 AM, Jerry Snitselaar wrote:
iommu_group_create_direct_mappings uses group->default_domain, but
right after it is called, request_default_domain_for_dev calls
iommu_domain_free for the default domain, and sets the group default
domain to a different domain. Move the
Hi Zhangfei,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on cryptodev/master]
[also build test ERROR on crypto/master char-misc/char-misc-testing v5.5-rc1
next-20191210]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve
[+cc Joerg]
On Tue, Dec 03, 2019 at 03:43:53PM +, James Sewart wrote:
> pci_add_dma_alias can now be used to create a dma alias for a range of
> devfns.
>
> Reviewed-by: Logan Gunthorpe
> Signed-off-by: James Sewart
> ---
> drivers/pci/pci.c| 22 +-
>
[+cc Joerg]
On Tue, Dec 03, 2019 at 03:43:22PM +, James Sewart wrote:
> The number of possible devfns is 256, add def and correct uses.
>
> Reviewed-by: Logan Gunthorpe
> Signed-off-by: James Sewart
I applied these three patches to pci/virtualization for v5.6, thanks!
I moved the
On Tue Dec 10 19, Lu Baolu wrote:
Hi,
On 12/10/19 1:18 PM, Jerry Snitselaar wrote:
On Mon Dec 09 19, Jerry Snitselaar wrote:
[snip]
A call to iommu_map is failing.
[ 36.686881] pci :01:00.2: iommu_group_add_device: calling
iommu_group_create_direct_mappings
[ 36.689843] pci
On Mon, Dec 09, 2019 at 07:05:13PM +0100, Jean-Philippe Brucker wrote:
> The SMMUv3 driver, which may be built without CONFIG_PCI, will soon gain
> PASID support. Partially revert commit c6e9aefbf9db ("PCI/ATS: Remove
> unused PRI and PASID stubs") to re-introduce the PASID stubs, and avoid
>
On Tue, 10 Dec 2019 09:14:07 +0800
Lu Baolu wrote:
> Hi Jacob,
>
> This has been queued for internal test. I will forward it to Joerg if
> everything goes well (probably around rc4).
>
Thanks for the confirmation. I will send out further patches based on
this series.
> Best regards,
> -baolu
min()/max() require the arguments to be of the same type.
When dma_addr_t is not compatible with __u64, this causes
a warning:
In file included from include/linux/list.h:9,
from include/linux/kobject.h:19,
from include/linux/of.h:17,
from
iommu_group_create_direct_mappings uses group->default_domain, but
right after it is called, request_default_domain_for_dev calls
iommu_domain_free for the default domain, and sets the group default
domain to a different domain. Move the
iommu_group_create_direct_mappings call to after the group
On 06/12/2019 21:38, Cong Wang wrote:
This patchset contains three small optimizations for the global spinlock
contention in IOVA cache. Our memcache perf test shows this reduced its
p999 latency down by 45% on AMD when IOMMU is enabled.
Cong Wang (3):
iommu: avoid unnecessary magazine
the system. BTW, we also suggest to use '--base' option to specify the
base tree in git format-patch, please see https://stackoverflow.com/a/37406982]
url:
https://github.com/0day-ci/linux/commits/Zhangfei-Gao/Add-uacce-module-for-Accelerator/20191210-160210
base:
https://git.kernel.org/pub/scm
On 10/12/2019 9:28 am, Stephan Gerhold wrote:
On Mon, Dec 09, 2019 at 01:08:32PM +, Robin Murphy wrote:
It makes little sense for dma_limit to be a dma_addr_t when we only use
it to pass u64 arguments, and combine it with another u64 along the way.
Just make it u64, and head off any
On Mon, Dec 09, 2019 at 01:08:32PM +, Robin Murphy wrote:
> It makes little sense for dma_limit to be a dma_addr_t when we only use
> it to pass u64 arguments, and combine it with another u64 along the way.
> Just make it u64, and head off any possible size mismatches.
>
> Signed-off-by:
26 matches
Mail list logo
