On Mon, Jun 15, 2020 at 3:20 PM Lu Baolu wrote:
>
> Hi Koba Ko,
>
> On 2020/6/15 11:19, Koba Ko wrote:
> > hi All,
> > I have a machine and there's only intel gpu.
> > the secureboot and vt-d is enabled in BIOS.
> > On the Ubuntu desktop, I do s2idle first and restart the machine.
> > The machine
> From: Lu Baolu
> Sent: Sunday, June 28, 2020 8:34 AM
>
> After a page request is handled, software must response the device which
> raised the page request with the handling result. This is done through
> the iommu ops.page_response if the request was reported to outside of
> vendor iommu
On 30/06/2020 01:10, Krishna Reddy wrote:
> NVIDIA's Tegra194 SoC uses two ARM MMU-500s together to interleave
> IOVA accesses across them.
> Add NVIDIA implementation for dual ARM MMU-500s and add new compatible
> string for Tegra194 SoC SMMU topology.
There is no description here of the 3rd
Hi Jerry,
On Fri, Jun 12, 2020 at 04:10:59PM -0700, Jerry Snitselaar wrote:
> Move Intel Kconfig and Makefile bits down into intel directory
> with the rest of the Intel specific files.
>
> Cc: Joerg Roedel
> Cc: Lu Baolu
> Signed-off-by: Jerry Snitselaar
> ---
> drivers/iommu/Kconfig
On Fri, Jun 26, 2020 at 08:30:21AM -0400, Qian Cai wrote:
> BTW, from the previous discussion, Linus mentioned,
>
> “
> The thing is, the 64-bit atomic reads/writes are very expensive on
> 32-bit x86. If it was just a native pointer, it would be much cheaper
> than an "atomic64_t".
> “
>
>
On Mon, Jun 29, 2020 at 05:29:36PM +0100, Robin Murphy wrote:
> On 2020-06-29 13:11, Geert Uytterhoeven wrote:
> > If NO_DMA=y (e.g. Sun-3 all{mod,yes}-config):
> >
> > drivers/iommu/dma-iommu.o: In function `iommu_dma_mmap':
> > dma-iommu.c:(.text+0x92e): undefined reference to
On 29/06/2020 23:49, Krishna Reddy wrote:
>>> + if (!nvidia_smmu->bases[0])
>>> + nvidia_smmu->bases[0] = smmu->base;
>>> +
>>> + return nvidia_smmu->bases[inst] + (page << smmu->pgshift); }
>
>> Not critical -- just a nit: why not put the bases[0] in init()?
>
> smmu->base
On Mon, Jun 29, 2020 at 09:49:41PM -0700, Rajat Jain wrote:
> Add a new (optional) field to denote the physical location of a device
> in the system, and expose it in sysfs. This was discussed here:
> https://lore.kernel.org/linux-acpi/20200618184621.ga446...@kroah.com/
>
> (The primary choice
On 2020-06-30 11:09, Joerg Roedel wrote:
On Mon, Jun 29, 2020 at 05:29:36PM +0100, Robin Murphy wrote:
On 2020-06-29 13:11, Geert Uytterhoeven wrote:
If NO_DMA=y (e.g. Sun-3 all{mod,yes}-config):
drivers/iommu/dma-iommu.o: In function `iommu_dma_mmap':
dma-iommu.c:(.text+0x92e):
On Mon, 2020-06-29 at 12:28 +0200, Matthias Brugger wrote:
>
> On 29/06/2020 09:13, Chao Hao wrote:
> > MT8173 is different from other SoCs for MMU_CTRL register.
> > For mt8173, its bit9 is in_order_write_en and doesn't use its
> > default 1'b1.> For other SoCs, bit[12] represents victim_tlb_en
On Tue, 2020-06-30 at 18:56 +0800, Yong Wu wrote:
> Hi Chao,
>
> This is also ok for me. Only two format nitpick.
>
> On Mon, 2020-06-29 at 15:13 +0800, Chao Hao wrote:
> > Given the fact that we are adding more and more plat_data bool values,
> > it would make sense to use a u32 flags register
On Mon, Jun 29, 2020 at 09:49:41PM -0700, Rajat Jain wrote:
> Add a new (optional) field to denote the physical location of a device
> in the system, and expose it in sysfs. This was discussed here:
> https://lore.kernel.org/linux-acpi/20200618184621.ga446...@kroah.com/
>
> (The primary choice
On Mon, Jun 29, 2020 at 09:49:40PM -0700, Rajat Jain wrote:
> device_attach() returning failure indicates a driver error while trying to
> probe the device. In such a scenario, the PCI device should still be added
> in the system and be visible to the user.
>
> This patch partially reverts:
>
Add brackets to protect parameters of the recently added sg_table related
macros from side-effects.
Fixes: 709d6d73c756 ("scatterlist: add generic wrappers for iterating over
sgtable objects")
Signed-off-by: Marek Szyprowski
---
include/linux/scatterlist.h | 8
1 file changed, 4
Move the recently added sg_table wrapper out of CONFIG_IOMMU_SUPPORT to
let the client code copile also when IOMMU support is disabled.
Fixes: 48530d9fab0d ("iommu: add generic helper for mapping sgtable objects")
Signed-off-by: Marek Szyprowski
---
include/linux/iommu.h | 32
On Sun, Jun 28, 2020 at 08:08:43PM +0200, Maxime Ripard wrote:
> The flush_all_tlb call back can be called from an atomic context, so using
> readl_poll_timeout that embeds a udelay doesn't work.
>
> Fixes: 4100b8c229b3 ("iommu: Add Allwinner H6 IOMMU driver")
> Signed-off-by: Maxime Ripard
On Mon, 2020-06-29 at 11:28 +0200, Matthias Brugger wrote:
>
> On 29/06/2020 09:13, Chao Hao wrote:
> > Add F_MMU_IN_ORDER_WR_EN and F_MMU_STANDARD_AXI_MODE_BIT definition
> > in MISC_CTRL register.
> > F_MMU_STANDARD_AXI_MODE_BIT:
> > If we set F_MMU_STANDARD_AXI_MODE_BIT(bit[3][19] = 0, not
On Sat, Jun 06, 2020 at 12:16:17PM -0700, Joe Perches wrote:
> CONFIG_BIG_ENDIAN does not exist as a Kconfig symbol.
>
> Signed-off-by: Joe Perches
> ---
>
> I don't have the hardware, so I can't tell if this is a
> correct change, but it is a logical one.
>
> Found by a test script that looks
Hi Chao,
This is also ok for me. Only two format nitpick.
On Mon, 2020-06-29 at 15:13 +0800, Chao Hao wrote:
> Given the fact that we are adding more and more plat_data bool values,
> it would make sense to use a u32 flags register and add the appropriate
> macro definitions to set and check for
On 2020/6/30 12:49, Rajat Jain wrote:
The firmware was provinding "ExternalFacing" attribute on PCI root ports,
to allow the kernel to mark devices behind it as external. Note that the
firmware provides an immutable, read-only property, i.e. the location of
the device.
The use of (external)
On 30/06/2020 01:10, Krishna Reddy wrote:
> Add binding for NVIDIA's Tegra194 SoC SMMU topology that is based
> on ARM MMU-500.
>
> Signed-off-by: Krishna Reddy
> ---
> Documentation/devicetree/bindings/iommu/arm,smmu.yaml | 5 +
> 1 file changed, 5 insertions(+)
>
> diff --git
Hi All,
On 19.06.2020 12:36, Marek Szyprowski wrote:
> During the Exynos DRM GEM rework and fixing the issues in the.
> drm_prime_sg_to_page_addr_arrays() function [1] I've noticed that most
> drivers in DRM framework incorrectly use nents and orig_nents entries of
> the struct sg_table.
>
> In
Hi Sebastian,
On Fri, Jun 05, 2020 at 04:56:55PM +0200, Sebastian Ott wrote:
> Add a check to enforce that I/O virtual addresses picked by iommu API
> users stay within the domains geometry aperture.
>
> Signed-off-by: Sebastian Ott
> ---
> drivers/iommu/amd_iommu.c | 5 +
> 1 file
On Tue, Jun 16, 2020 at 04:47:14PM +0200, Jean-Philippe Brucker wrote:
> Some PCIe devices do not expect a PASID value in PRI Page Responses.
> If the "PRG Response PASID Required" bit in the PRI capability is zero,
> then the OS should not set the PASID field. Similarly on Arm SMMU,
> responses
On 21.06.2020 06:00, Dmitry Osipenko wrote:
> В Fri, 19 Jun 2020 12:36:31 +0200
> Marek Szyprowski пишет:
>
>> The Documentation/DMA-API-HOWTO.txt states that the dma_map_sg()
>> function returns the number of the created entries in the DMA address
>> space. However the subsequent calls to the
>>
On Tue, Jun 30, 2020 at 11:06:41AM +0800, Hanjun Guo wrote:
[...]
> > For devices that aren't described in the DSDT - IORT translations
> > are determined by their ACPI parent device. Do you see/Have you
> > found any issue with this approach ?
>
> The spec says "Describes the IO relationships
On Tue, 2020-06-30 at 18:55 +0800, Yong Wu wrote:
> On Mon, 2020-06-29 at 15:13 +0800, Chao Hao wrote:
> > The max larb number that a iommu HW support is 8(larb0~larb7 in the below
> > diagram).
> > If the larb's number is over 8, we use a sub_common for merging
> > several larbs into one larb. At
On 2020/6/30 12:49, Rajat Jain wrote:
The "ExternalFacing" devices (root ports) are still internal devices that
sit on the internal system fabric and thus trusted. Currently they were
being marked untrusted.
This patch uses the platform flag to identify the external facing devices
and then use
On Mon, Jun 29, 2020 at 09:49:38PM -0700, Rajat Jain wrote:
> The "ExternalFacing" devices (root ports) are still internal devices that
> sit on the internal system fabric and thus trusted. Currently they were
> being marked untrusted.
>
> This patch uses the platform flag to identify the
On 30/06/2020 01:10, Krishna Reddy wrote:
> Add global/context fault hooks to allow NVIDIA SMMU implementation
> handle faults across multiple SMMUs.
Nit ... this is not just for NVIDIA, but this allows anyone to add
custom global/context and fault hooks. So I think that the changelog
should be
On Thu, Jun 25, 2020 at 03:08:23PM +0200, Joerg Roedel wrote:
> Joerg Roedel (13):
> iommu/exynos: Use dev_iommu_priv_get/set()
> iommu/vt-d: Use dev_iommu_priv_get/set()
> iommu/msm: Use dev_iommu_priv_get/set()
> iommu/omap: Use dev_iommu_priv_get/set()
> iommu/rockchip: Use
On Tue, Jun 30, 2020 at 10:17:56AM +0200, Marek Szyprowski wrote:
> Move the recently added sg_table wrapper out of CONFIG_IOMMU_SUPPORT to
> let the client code copile also when IOMMU support is disabled.
>
> Fixes: 48530d9fab0d ("iommu: add generic helper for mapping sgtable objects")
>
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 already properly did all the
scaterlist related calls.
On 2020-06-30 09:37, Jon Hunter wrote:
On 30/06/2020 01:10, Krishna Reddy wrote:
Add global/context fault hooks to allow NVIDIA SMMU implementation
handle faults across multiple SMMUs.
Nit ... this is not just for NVIDIA, but this allows anyone to add
custom global/context and fault hooks.
On Thu, Jun 04, 2020 at 06:32:06PM -0700, Sai Praneeth Prakhya wrote:
> +static int iommu_change_dev_def_domain(struct iommu_group *group, int type)
> +{
> + struct iommu_domain *prev_dom;
> + struct group_device *grp_dev;
> + const struct iommu_ops *ops;
> + int ret, dev_def_dom;
On Thu, Jun 11, 2020 at 08:10:28PM +0900, Yoshihiro Shimoda wrote:
> This patch series is based on next-20200611.
>
> Yoshihiro Shimoda (2):
> dt-bindings: iommu: renesas,ipmmu-vmsa: add r8a77961 support
> iommu/renesas: Add support for r8a77961
Applied, thanks.
On Wed, Jun 17, 2020 at 12:04:20AM +0200, Paul Menzel wrote:
> drivers/iommu/amd_iommu_init.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
Applied, thanks.
___
iommu mailing list
iommu@lists.linux-foundation.org
On 30/06/2020 01:10, Krishna Reddy wrote:
> NVIDIA's Tegra194 SoC uses two ARM MMU-500s together to interleave
> IOVA accesses across them.
> Add NVIDIA implementation for dual ARM MMU-500s and add new compatible
> string for Tegra194 SoC SMMU topology.
>
> Signed-off-by: Krishna Reddy
> ---
>
On Fri, Jun 05, 2020 at 12:00:25AM -0700, Jerry Snitselaar wrote:
> When include/uapi/linux/iommu.h was created it was never
> added to the file list in MAINTAINERS.
>
> Cc: Joerg Roedel
> Signed-off-by: Jerry Snitselaar
> ---
> MAINTAINERS | 1 +
> 1 file changed, 1 insertion(+)
Applied,
On Mon, 2020-06-29 at 12:16 +0200, Matthias Brugger wrote:
>
> On 29/06/2020 09:13, Chao Hao wrote:
> > Some platforms(ex: mt6779) need to improve performance by setting
> > REG_MMU_WR_LEN register. And we can use WR_THROT_EN macro to control
> > whether we need to set the register. If the
On Mon, 2020-06-29 at 15:13 +0800, Chao Hao wrote:
> The max larb number that a iommu HW support is 8(larb0~larb7 in the below
> diagram).
> If the larb's number is over 8, we use a sub_common for merging
> several larbs into one larb. At this case, we will extend larb_id:
> bit[11:9] means
> Add binding for NVIDIA's Tegra194 SoC SMMU topology that is based on ARM
> MMU-500.
>
> Signed-off-by: Krishna Reddy
Reviewed-by: Pritesh Raithatha
___
iommu mailing list
iommu@lists.linux-foundation.org
> NVIDIA's Tegra194 SoC uses two ARM MMU-500s together to interleave IOVA
> accesses across them.
> Add NVIDIA implementation for dual ARM MMU-500s and add new compatible
> string for Tegra194 SoC SMMU topology.
>
> Signed-off-by: Krishna Reddy
Reviewed-by: Pritesh Raithatha
> Add global/context fault hooks to allow NVIDIA SMMU implementation handle
> faults across multiple SMMUs.
>
> Signed-off-by: Krishna Reddy
Reviewed-by: Pritesh Raithatha
___
iommu mailing list
iommu@lists.linux-foundation.org
Hi Koba,
On 2020/6/30 15:31, Koba Ko wrote:
On Mon, Jun 15, 2020 at 3:20 PM Lu Baolu wrote:
Hi Koba Ko,
On 2020/6/15 11:19, Koba Ko wrote:
hi All,
I have a machine and there's only intel gpu.
the secureboot and vt-d is enabled in BIOS.
On the Ubuntu desktop, I do s2idle first and restart
The Documentation/DMA-API-HOWTO.txt states that the dma_map_sg() function
returns the number of the created entries in the DMA address space.
However the subsequent calls to the dma_sync_sg_for_{device,cpu}() and
dma_unmap_sg must be called with the original number of the entries
passed to the
On Tue, Jun 02, 2020 at 02:08:18PM +0100, Robin Murphy wrote:
> Unlike the other instances which represent a complete loss of
> consistency within the rcache mechanism itself, or a fundamental
> and obvious misconfiguration by an IOMMU driver, the BUG_ON() in
> iova_magazine_free_pfns() can be
On 2020-06-30 11:23, Jon Hunter wrote:
On 29/06/2020 23:49, Krishna Reddy wrote:
+ if (!nvidia_smmu->bases[0])
+ nvidia_smmu->bases[0] = smmu->base;
+
+ return nvidia_smmu->bases[inst] + (page << smmu->pgshift); }
Not critical -- just a nit: why not put the bases[0] in
On 2020-06-30 01:10, Krishna Reddy wrote:
Add binding for NVIDIA's Tegra194 SoC SMMU topology that is based
on ARM MMU-500.
Signed-off-by: Krishna Reddy
---
Documentation/devicetree/bindings/iommu/arm,smmu.yaml | 5 +
1 file changed, 5 insertions(+)
diff --git
From: Joerg Roedel
At least the version in the header file to fix a compile warning about
the function being unused.
Reported-by: Borislav Petkov
Signed-off-by: Joerg Roedel
---
drivers/iommu/amd/amd_iommu.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
On Tue, Jun 30, 2020 at 2:52 PM Greg Kroah-Hartman
wrote:
>
> On Tue, Jun 30, 2020 at 01:49:48PM +0300, Heikki Krogerus wrote:
> > On Mon, Jun 29, 2020 at 09:49:41PM -0700, Rajat Jain wrote:
> > > Add a new (optional) field to denote the physical location of a device
> > > in the system, and
On 2020/6/30 18:24, Lorenzo Pieralisi wrote:
On Tue, Jun 30, 2020 at 11:06:41AM +0800, Hanjun Guo wrote:
[...]
For devices that aren't described in the DSDT - IORT translations
are determined by their ACPI parent device. Do you see/Have you
found any issue with this approach ?
The spec says
On 2020-06-30 09:19, Jon Hunter wrote:
On 30/06/2020 01:10, Krishna Reddy wrote:
NVIDIA's Tegra194 SoC uses two ARM MMU-500s together to interleave
IOVA accesses across them.
Add NVIDIA implementation for dual ARM MMU-500s and add new compatible
string for Tegra194 SoC SMMU topology.
There
On Tue, Jun 30, 2020 at 03:00:34PM +0200, Rafael J. Wysocki wrote:
> On Tue, Jun 30, 2020 at 2:52 PM Greg Kroah-Hartman
> wrote:
> >
> > On Tue, Jun 30, 2020 at 01:49:48PM +0300, Heikki Krogerus wrote:
> > > On Mon, Jun 29, 2020 at 09:49:41PM -0700, Rajat Jain wrote:
> > > > Add a new (optional)
On 30/06/2020 13:13, Robin Murphy wrote:
> On 2020-06-30 09:37, Jon Hunter wrote:
>>
>> On 30/06/2020 01:10, Krishna Reddy wrote:
>>> Add global/context fault hooks to allow NVIDIA SMMU implementation
>>> handle faults across multiple SMMUs.
>>
>> Nit ... this is not just for NVIDIA, but this
On Tue, Jun 30, 2020 at 01:49:48PM +0300, Heikki Krogerus wrote:
> On Mon, Jun 29, 2020 at 09:49:41PM -0700, Rajat Jain wrote:
> > Add a new (optional) field to denote the physical location of a device
> > in the system, and expose it in sysfs. This was discussed here:
> >
On 6/30/20 7:07 AM, Christoph Hellwig wrote:
On Mon, Jun 29, 2020 at 05:18:38PM +0200, Daniel Borkmann wrote:
On 6/29/20 5:10 PM, Björn Töpel wrote:
On 2020-06-29 15:52, Daniel Borkmann wrote:
Ok, fair enough, please work with DMA folks to get this properly integrated and
restored then.
On 30/06/2020 15:53, Robin Murphy wrote:
> On 2020-06-30 09:19, Jon Hunter wrote:
>>
>> On 30/06/2020 01:10, Krishna Reddy wrote:
>>> NVIDIA's Tegra194 SoC uses two ARM MMU-500s together to interleave
>>> IOVA accesses across them.
>>> Add NVIDIA implementation for dual ARM MMU-500s and add new
On 30/06/2020 17:32, Jon Hunter wrote:
> On 30/06/2020 17:23, Krishna Reddy wrote:
+struct arm_smmu_device *nvidia_smmu_impl_init(struct arm_smmu_device
+*smmu) {
+ unsigned int i;
>>
+ for (i = 1; i < MAX_SMMU_INSTANCES; i++) {
+ struct resource *res;
On Thu, 25 Jun 2020 18:05:52 +0800
Lu Baolu wrote:
> Hi,
>
> On 2020/6/23 23:43, Jacob Pan wrote:
> > From: Liu Yi L
> >
> > Address information for device TLB invalidation comes from userspace
> > when device is directly assigned to a guest with vIOMMU support.
> > VT-d requires page aligned
On 30/06/2020 18:16, Krishna Reddy wrote:
>> OK, well I see what you are saying, but if we intended to support all 3 for
>> Tegra194, then we should ensure all 3 are initialised correctly.
>
> The driver intend to support up to 3 instances. It doesn't really mandate
> that all three instances
On Tue, Jun 30, 2020 at 5:38 PM Greg Kroah-Hartman
wrote:
>
> On Tue, Jun 30, 2020 at 03:00:34PM +0200, Rafael J. Wysocki wrote:
> > On Tue, Jun 30, 2020 at 2:52 PM Greg Kroah-Hartman
> > wrote:
> > >
> > > On Tue, Jun 30, 2020 at 01:49:48PM +0300, Heikki Krogerus wrote:
> > > > On Mon, Jun 29,
On 30/06/2020 17:23, Krishna Reddy wrote:
>>> +struct arm_smmu_device *nvidia_smmu_impl_init(struct arm_smmu_device
>>> +*smmu) {
>>> + unsigned int i;
>
>>> + for (i = 1; i < MAX_SMMU_INSTANCES; i++) {
>>> + struct resource *res;
>>> +
>>> + res =
On Thu, 25 Jun 2020 18:10:43 +0800
Lu Baolu wrote:
> Hi,
>
> On 2020/6/23 23:43, Jacob Pan wrote:
> > For guest requested IOTLB invalidation, address and mask are
> > provided as part of the invalidation data. VT-d HW silently ignores
> > any address bits below the mask. SW shall also allow
On Tue, 16 Jun 2020, Suravee Suthikulpanit wrote:
> > > On 6/1/20 4:01 PM, Alexander Monakov wrote:
> > > > On Mon, 1 Jun 2020, Suravee Suthikulpanit wrote:
> > > >
> > > > > > Moving init_iommu_perf_ctr just after iommu_flush_all_caches
> > > > > > resolves the issue. This is the earliest point
On 2020-06-30 02:03, Lu Baolu wrote:
Hi Robin,
On 6/29/20 7:56 PM, Robin Murphy wrote:
On 2020-06-27 04:15, Lu Baolu wrote:
The hardware assistant vfio mediated device is a use case of iommu
aux-domain. The interactions between vfio/mdev and iommu during mdev
creation and passthr are:
-
>OK, well I see what you are saying, but if we intended to support all 3 for
>Tegra194, then we should ensure all 3 are initialised correctly.
The driver intend to support up to 3 instances. It doesn't really mandate that
all three instances be present in same DT node.
Each mmio aperture in
>> +struct arm_smmu_device *nvidia_smmu_impl_init(struct arm_smmu_device
>> +*smmu) {
>> +unsigned int i;
>> +for (i = 1; i < MAX_SMMU_INSTANCES; i++) {
>> +struct resource *res;
>> +
>> +res = platform_get_resource(pdev, IORESOURCE_MEM, i);
>> +if
>> NVIDIA's Tegra194 SoC uses two ARM MMU-500s together to interleave
>> IOVA accesses across them.
>> Add NVIDIA implementation for dual ARM MMU-500s and add new compatible
>> string for Tegra194 SoC SMMU topology.
>There is no description here of the 3rd SMMU that you mention below.
>I think
On Tue, 30 Jun 2020 02:52:45 +
"Tian, Kevin" wrote:
> > From: Jacob Pan
> > Sent: Tuesday, June 30, 2020 7:05 AM
> >
> > On Fri, 26 Jun 2020 16:19:23 -0600
> > Alex Williamson wrote:
> >
> > > On Tue, 23 Jun 2020 10:03:53 -0700
> > > Jacob Pan wrote:
> > >
> > > > IOMMU UAPI is newly
On Tue, Jun 30, 2020 at 06:08:31PM +0200, Rafael J. Wysocki wrote:
> On Tue, Jun 30, 2020 at 5:38 PM Greg Kroah-Hartman
> wrote:
> >
> > On Tue, Jun 30, 2020 at 03:00:34PM +0200, Rafael J. Wysocki wrote:
> > > On Tue, Jun 30, 2020 at 2:52 PM Greg Kroah-Hartman
> > > wrote:
> > > >
> > > > On
On Mon, Jun 29, 2020 at 9:49 PM Rajat Jain wrote:
>
> Add a new (optional) field to denote the physical location of a device
> in the system, and expose it in sysfs. This was discussed here:
> https://lore.kernel.org/linux-acpi/20200618184621.ga446...@kroah.com/
>
> (The primary choice for
On Mon, Jun 29, 2020 at 02:15:16PM +0100, Robin Murphy wrote:
> On 2020-06-27 08:02, Christoph Hellwig wrote:
> > On Fri, Jun 26, 2020 at 01:54:12PM -0700, Jonathan Lemon wrote:
> > > On Fri, Jun 26, 2020 at 09:47:25AM +0200, Christoph Hellwig wrote:
> > > >
> > > > Note that this is somewhat
Move Intel Kconfig and Makefile bits down into intel directory
with the rest of the Intel specific files.
Cc: Joerg Roedel
Cc: Lu Baolu
Signed-off-by: Jerry Snitselaar
---
drivers/iommu/Kconfig| 86 +---
drivers/iommu/Makefile | 8 +---
Move AMD Kconfig and Makefile bits down into the amd directory
with the rest of the AMD specific files.
Cc: Joerg Roedel
Cc: Suravee Suthikulpanit
Signed-off-by: Jerry Snitselaar
---
drivers/iommu/Kconfig | 45 +-
drivers/iommu/Makefile | 5 +
This patchset imeplements the suggestion from Linus to move the
Kconfig and Makefile bits for AMD and Intel into their respective
directories.
v2: Rebase against v5.8-rc3. Dropped ---help--- changes from Kconfig as that was
dealt with in systemwide cleanup.
Jerry Snitselaar (2):
On Fri, Jun 19, 2020 at 2:20 AM Lorenzo Pieralisi
wrote:
>
> There is nothing PCI bus specific in the of_msi_map_rid()
> implementation other than the requester ID tag for the input
> ID space. Rename requester ID to a more generic ID so that
> the translation code can be used by all busses that
>> The driver intend to support up to 3 instances. It doesn't really mandate
>> that all three instances be present in same DT node.
>> Each mmio aperture in "reg" property is an instance here. reg =
>> , , ; The reg can have
>> all three or less and driver just configures based on reg and it
On Fri, Jun 19, 2020 at 2:20 AM Lorenzo Pieralisi
wrote:
>
> Devices sitting on proprietary busses have a device ID space that
> is owned by the respective bus and related firmware bindings. In order
> to let the generic OF layer handle the input translations to
> an IOMMU id, for such busses the
On Fri, Jun 19, 2020 at 2:20 AM Lorenzo Pieralisi
wrote:
>
> From: Diana Craciun
>
> of_msi_map_get_device_domain() is PCI specific but it need not be and
> can be easily changed to be bus agnostic in order to be used by other
> busses by adding an IRQ domain bus token as an input parameter.
>
>
On Fri, Jun 19, 2020 at 2:20 AM Lorenzo Pieralisi
wrote:
>
> From: Laurentiu Tudor
>
> The existing bindings cannot be used to specify the relationship
> between fsl-mc devices and GIC ITSes.
> Add a generic binding for mapping fsl-mc devices to GIC ITSes, using
> msi-map property.
> In
From: Liu Yi L
For guest SVA usage, in order to optimize for less VMEXIT, guest request
of IOTLB flush also includes device TLB.
On the host side, IOMMU driver performs IOTLB and implicit devTLB
invalidation. When PASID-selective granularity is requested by the guest
we need to derive the
Global pages support is removed from VT-d spec 3.0 for dev TLB
invalidation. This patch is to remove the bits for vSVA. Similar change
already made for the native SVA. See the link below.
Link: https://lkml.org/lkml/2019/8/26/651
Acked-by: Lu Baolu
Signed-off-by: Jacob Pan
---
For the unlikely use case where multiple aux domains from the same pdev
are attached to a single guest and then bound to a single process
(thus same PASID) within that guest, we cannot easily support this case
by refcounting the number of users. As there is only one SL page table
per PASID while
From: Liu Yi L
Set proper masks to avoid invalid input spillover to reserved bits.
Acked-by: Lu Baolu
Signed-off-by: Liu Yi L
Signed-off-by: Jacob Pan
---
include/linux/intel-iommu.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/include/linux/intel-iommu.h
DevTLB flush can be used for both DMA request with and without PASIDs.
The former uses PASID#0 (RID2PASID), latter uses non-zero PASID for SVA
usage.
This patch adds a check for PASID value such that devTLB flush with
PASID is used for SVA case. This is more efficient in that multiple
PASIDs can
For guest requested IOTLB invalidation, address and mask are provided as
part of the invalidation data. VT-d HW silently ignores any address bits
below the mask. SW shall also allow such case but give warning if
address does not align with the mask. This patch relax the fault
handling from error
Hi Baolu and all,
This is a series to address some of the issues we found in vSVA support.
Most of the patches deal with exception handling, we also removed some bits
that are not currently supported.
Many thanks to Kevin Tian's review.
Jacob & Yi
Changelog:
v2 Address reviews from Baolu
From: Liu Yi L
Address information for device TLB invalidation comes from userspace
when device is directly assigned to a guest with vIOMMU support.
VT-d requires page aligned address. This patch checks and enforce
address to be page aligned, otherwise reserved bits can be set in the
Hi Jacob,
On 7/1/20 1:34 AM, Jacob Pan wrote:
On Thu, 25 Jun 2020 18:10:43 +0800
Lu Baolu wrote:
Hi,
On 2020/6/23 23:43, Jacob Pan wrote:
For guest requested IOTLB invalidation, address and mask are
provided as part of the invalidation data. VT-d HW silently ignores
any address bits below
The IVRS ACPI table specifies maximum address sizes for I/O virtual
addresses that can be handled by the IOMMUs in the system. Parse that
data from the IVRS header to provide aperture information for DMA
mappings and users of the iommu API.
Changes for V2:
- use limits in iommu_setup_dma_ops()
Add a check to enforce that I/O virtual addresses picked by iommu API
users stay within the domains geometry aperture.
Signed-off-by: Sebastian Ott
Cc: Benjamin Serebrin
Cc: Filippo Sironi
CR: https://code.amazon.com/reviews/CR-26408388
---
drivers/iommu/amd/iommu.c | 9 -
1 file
The IVRS ACPI table specifies maximum address sizes for i/o virtual
addresses that can be handled by the IOMMUs in the system. Parse that
data from the IVRS header so that it can be considered in limiting the
IO aperture (in subsequent patches).
Based on prior work by Marius Hillenbrand.
Link:
The IVRS ACPI table specifies maximum address sizes for I/O virtual
addresses. When allocating new protection domains that perform
translation, propagate these limits as the domain's geometry / aperture.
Based on prior work by Marius Hillenbrand.
Signed-off-by: Sebastian Ott
Cc: Benjamin
The PASID state has to be cleared on forks, since the child has a
different address space. The PASID is also cleared for thread clone. While
it would be correct to inherit the PASID in this case, it is unknown
whether the new task will use ENQCMD. Giving it the PASID "just in case"
would have the
From: Ashok Raj
ENQCMD and Data Streaming Accelerator (DSA) and all of their associated
features are a complicated stack with lots of interconnected pieces.
This documentation provides a big picture overview for all of the
features.
Signed-off-by: Ashok Raj
Co-developed-by: Fenghua Yu
PASID is defined as a few different types in iommu including "int",
"u32", and "unsigned int". To be consistent and to match with uapi
definitions, define PASID and its variations (e.g. max PASID) as "u32".
"u32" is also shorter and a little more explicit than "unsigned int".
No PASID type change
When a new mm is created, its PASID should be cleared, i.e. the PASID is
initialized to its init state 0 on both ARM and X86.
Signed-off-by: Fenghua Yu
Reviewed-by: Tony Luck
---
v2:
- Add this patch to initialize PASID value for a new mm.
include/linux/mm_types.h | 2 ++
kernel/fork.c
Work submission instruction comes in two flavors. ENQCMD can be called
both in ring 3 and ring 0 and always uses the contents of PASID MSR when
shipping the command to the device. ENQCMDS allows a kernel driver to
submit commands on behalf of a user process. The driver supplies the
PASID value in
PASID is shared by all threads in a process. So the logical place to keep
track of it is in the "mm". Both ARM and X86 need to use the PASID in the
"mm".
Suggested-by: Christoph Hellwig
Signed-off-by: Fenghua Yu
Reviewed-by: Tony Luck
---
v4:
- Change PASID type to u32 (Christoph)
v3:
-
1 - 100 of 123 matches
Mail list logo
