So that it could be used in other source files as well.
Cc: Ashok Raj
Cc: Jacob Pan
Cc: Kevin Tian
Cc: Liu Yi L
Cc: Yi Sun
Signed-off-by: Lu Baolu
---
drivers/iommu/intel-iommu.c | 7 ---
include/linux/intel-iommu.h | 7 +++
2 files changed, 7 insertions(+), 7 deletions(-)
diff
.
intel_mmunmap_range(domain, addr, end)
- Tear down the map of an iova range [addr, end). A page
list will be returned which will be freed after iotlb
flushing.
Cc: Ashok Raj
Cc: Jacob Pan
Cc: Kevin Tian
Cc: Liu Yi L
Cc: Yi Sun
Signed-off-by: Lu Baolu
---
drivers/iommu/Makefile | 2
This checks whether a domain should use first level page table
for map/unmap. And if so, we should attach the domain to the
device in first level translation mode.
Cc: Ashok Raj
Cc: Jacob Pan
Cc: Kevin Tian
Cc: Liu Yi L
Cc: Yi Sun
Cc: Sanjay Kumar
Signed-off-by: Lu Baolu
---
drivers/iommu
If a dmar domain has DOMAIN_FLAG_FIRST_LEVEL_TRANS bit set
in its flags, IOMMU will use the first level page table for
translation. Hence, we need to map or unmap addresses in the
first level page table.
Cc: Ashok Raj
Cc: Jacob Pan
Cc: Kevin Tian
Cc: Liu Yi L
Cc: Yi Sun
Signed-off-by: Lu
Hi Ashok,
On 9/24/19 4:31 AM, Raj, Ashok wrote:
On Mon, Sep 23, 2019 at 08:24:52PM +0800, Lu Baolu wrote:
This adds functions to manipulate first level page tables
which could be used by a scalale mode capable IOMMU unit.
s/scalale/scalable
Yes.
intel_mmmap_range(domain, addr, end
Hi Jacob,
On 9/24/19 3:27 AM, Jacob Pan wrote:
Hi Baolu,
On Mon, 23 Sep 2019 20:24:50 +0800
Lu Baolu wrote:
This patchset aims to move IOVA (I/O Virtual Address) translation
to 1st-level page table under scalable mode. The major purpose of
this effort is to make guest IOVA support more
Hi,
On 9/24/19 4:25 AM, Raj, Ashok wrote:
Hi Jacob
On Mon, Sep 23, 2019 at 12:27:15PM -0700, Jacob Pan wrote:
In VT-d 3.0, scalable mode is introduced, which offers two level
translation page tables and nested translation mode. Regards to
GIOVA support, it can be simplified by 1) moving the G
Hi Kevin,
On 9/24/19 3:00 PM, Tian, Kevin wrote:
'---'
'---'
This patch series only aims to achieve the first goal, a.k.a using
first goal? then what are other goals? I didn't spot such information.
The overall goal is to use IOMMU nested mode to avoid shadow pag
Hi Peter and Kevin,
On 9/25/19 1:24 PM, Peter Xu wrote:
On Wed, Sep 25, 2019 at 04:38:31AM +, Tian, Kevin wrote:
From: Peter Xu [mailto:pet...@redhat.com]
Sent: Wednesday, September 25, 2019 12:31 PM
On Tue, Sep 24, 2019 at 09:38:53AM +0800, Lu Baolu wrote:
intel_mmmap_range(domain, addr
Hi,
On 9/25/19 1:00 PM, Tian, Kevin wrote:
From: Lu Baolu [mailto:baolu...@linux.intel.com]
Sent: Monday, September 23, 2019 8:25 PM
If a dmar domain has DOMAIN_FLAG_FIRST_LEVEL_TRANS bit set
in its flags, IOMMU will use the first level page table for
translation. Hence, we need to map or
...@redhat.com]
Sent: Wednesday, September 25, 2019 2:57 PM
On Wed, Sep 25, 2019 at 10:48:32AM +0800, Lu Baolu wrote:
Hi Kevin,
On 9/24/19 3:00 PM, Tian, Kevin wrote:
'---'
'---'
This patch series only aims to achieve the first goal, a.k.a using
first
Hi Kevin,
On 9/25/19 3:32 PM, Tian, Kevin wrote:
From: Lu Baolu [mailto:baolu...@linux.intel.com]
Sent: Wednesday, September 25, 2019 2:52 PM
Hi Peter and Kevin,
On 9/25/19 1:24 PM, Peter Xu wrote:
On Wed, Sep 25, 2019 at 04:38:31AM +, Tian, Kevin wrote:
From: Peter Xu [mailto:pet
Hi Peter,
Thanks for reviewing my code.
On 9/25/19 1:21 PM, Peter Xu wrote:
On Mon, Sep 23, 2019 at 08:24:52PM +0800, Lu Baolu wrote:
This adds functions to manipulate first level page tables
which could be used by a scalale mode capable IOMMU unit.
intel_mmmap_range(domain, addr, end
Hi Peter,
On 9/26/19 11:49 AM, Peter Xu wrote:
On Thu, Sep 26, 2019 at 10:35:24AM +0800, Lu Baolu wrote:
[...]
@@ -0,0 +1,342 @@
+// SPDX-License-Identifier: GPL-2.0
+/**
+ * intel-pgtable.c - Intel IOMMU page table manipulation library
Could this be a bit misleading? Normally I'l
Hi Peter,
On 9/27/19 1:34 PM, Peter Xu wrote:
Hi, Baolu,
On Fri, Sep 27, 2019 at 10:27:24AM +0800, Lu Baolu wrote:
+ spin_lock(&(domain)->page_table_lock); \
Is this intended to lock here instead of taking the lock during the
whole page table walk?
Hi,
On 9/29/19 1:25 PM, Peter Xu wrote:
On Sat, Sep 28, 2019 at 04:23:16PM +0800, Lu Baolu wrote:
Hi Peter,
On 9/27/19 1:34 PM, Peter Xu wrote:
Hi, Baolu,
On Fri, Sep 27, 2019 at 10:27:24AM +0800, Lu Baolu wrote:
+ spin_lock(&(domain)->page_tab
Hi,
On 10/1/19 11:01 PM, Janusz Krzysztofik wrote:
Hi Baolu,
On Tuesday, September 3, 2019 9:41:23 AM CEST Janusz Krzysztofik wrote:
Hi Baolu,
On Tuesday, September 3, 2019 3:29:40 AM CEST Lu Baolu wrote:
Hi Janusz,
On 9/2/19 4:37 PM, Janusz Krzysztofik wrote:
I am not saying that keeping
Hi Janusz,
On 9/3/19 3:41 PM, Janusz Krzysztofik wrote:
Hi Baolu,
On Tuesday, September 3, 2019 3:29:40 AM CEST Lu Baolu wrote:
Hi Janusz,
On 9/2/19 4:37 PM, Janusz Krzysztofik wrote:
I am not saying that keeping data is not acceptable. I just want to
check whether there are any other
validation as a dummy function
Reviewed-by: Sohil Mehta
Signed-off-by: Yian Chen
This patch looks good to me.
Reviewed-by: Lu Baolu
---
arch/ia64/include/asm/iommu.h | 5 +
arch/x86/include/asm/iommu.h | 18 ++
drivers/iommu/intel-iommu.c | 8 +++-
3 files
Hi,
On 10/15/19 11:11 PM, Yuri Volchkov wrote:
For health monitoring, it can be useful to know if iommu is behaving as
expected. DMAR faults can be an indicator that a device:
- has been misconfigured, or
- has experienced a hardware hiccup and replacement should
be considered, or
- ha
Hi Ashok,
Thanks for reviewing the patch.
On 10/23/19 8:45 AM, Raj, Ashok wrote:
On Tue, Oct 22, 2019 at 04:53:14PM -0700, Jacob Pan wrote:
From: Lu Baolu
If Intel IOMMU runs in caching mode, a.k.a. virtual IOMMU, the
IOMMU driver should rely on the emulation software to allocate
and free
XArray based allocator. The resulting IOASID allocation will always
come from the host. This ensures that PASID namespace is system-
wide.
Signed-off-by: Lu Baolu
Signed-off-by: Liu, Yi L
Signed-off-by: Jacob Pan
---
drivers/iommu/Kconfig | 1 +
drivers/iommu/intel-iommu.c | 67
Hi,
On 10/24/19 1:55 AM, Jacob Pan wrote:
On Wed, 23 Oct 2019 09:53:04 +0800
Lu Baolu wrote:
Hi Ashok,
Thanks for reviewing the patch.
On 10/23/19 8:45 AM, Raj, Ashok wrote:
On Tue, Oct 22, 2019 at 04:53:14PM -0700, Jacob Pan wrote:
From: Lu Baolu
If Intel IOMMU runs in caching mode
Hi,
On 10/24/19 5:11 AM, Jacob Pan wrote:
On Wed, 23 Oct 2019 10:55:23 -0700
Jacob Pan wrote:
Do you have to check this everytime? every dmar_readq is going to
trap to the other side ...
Yes. We don't need to check it every time. Check once and save the
result during boot is enough.
How ab
Hi,
On 10/24/19 7:01 AM, Jacob Pan wrote:
On Wed, 23 Oct 2019 10:21:51 +0800
Lu Baolu wrote:
+#ifdef CONFIG_INTEL_IOMMU_SVM
Maybe move them to intel-svm.c instead? that's where the bulk
of the svm support is?
I think this is a generic PASID allocator for guest IOMMU although
vS
will always
come from the host. This ensures that PASID namespace is system-
wide.
Signed-off-by: Lu Baolu
Signed-off-by: Liu, Yi L
Signed-off-by: Jacob Pan
---
drivers/iommu/Kconfig | 1 +
drivers/iommu/intel-iommu.c | 67 +
include/linux
Hi,
On 10/25/19 3:54 AM, Jacob Pan wrote:
Virtual command registers are used in the guest only, to prevent
vmexit cost, we cache the capability and store it during initialization.
Signed-off-by: Jacob Pan
This patch looks good to me.
Reviewed-by: Lu Baolu
Best regards,
baolu
HI,
On 10/25/19 3:54 AM, Jacob Pan wrote:
Move domain helper to header to be used by SVA code.
Signed-off-by: Jacob Pan
Reviewed-by: Eric Auger
This patch looks good to me.
Reviewed-by: Lu Baolu
Best regards,
baolu
---
drivers/iommu/intel-iommu.c | 6 --
include/linux/intel
Hi,
On 10/25/19 3:54 AM, Jacob Pan wrote:
After each setup for PASID entry, related translation caches must be flushed.
We can combine duplicated code into one function which is less error prone.
Signed-off-by: Jacob Pan
This patch looks good to me.
Reviewed-by: Lu Baolu
Best regards
= intel_pasid_lookup_id(pasid);
- if (!svm)
+ svm = ioasid_find(NULL, pasid, NULL);
+ if (IS_ERR(svm)) {
Shall we check whether svm is NULL?
Others looks good to me.
Reviewed-by: Lu Baolu
Best regards,
baolu
___
iommu mailing list
iommu
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,
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
nction will return success. This isn't
expected, right?
Others looks good to me.
Reviewed-by: Lu Baolu
Best regards,
baolu
-
- list_for_each_entry(sdev, &svm->devs, list) {
- if (dev == sdev->dev) {
- ret = 0;
- s
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:
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: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 again,
On 10/26/19 10:40 AM, Lu Baolu wrote:
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
Hi Chris,
Just a quick scan of the dmesg attached in the bugzilla.
There are 6 devices reported in ANDD.
[0.458662] DMAR: ANDD device: 1 name: \_SB.PCI0.I2C0
[0.458683] DMAR: ANDD device: 2 name: \_SB.PCI0.I2C1
[0.458704] DMAR: ANDD device: 3 name: \_SB.PCI0.SPI0
[0.458724] DMAR
Hi,
On 10/29/19 6:49 AM, Jacob Pan wrote:
I'm not sure whether tying above logic to SVA is the right
approach. If vcmd interface doesn't work, the whole SM mode
doesn't make sense which is based on PASID-granular protection
(SVA is only one usage atop). If the only remaining usage of SM
is to ma
Hi,
On 10/28/19 2:03 PM, Tian, Kevin wrote:
.dev_disable_feat = intel_iommu_dev_disable_feat,
.is_attach_deferred =
intel_iommu_is_attach_deferred, .pgsize_bitmap =
INTEL_IOMMU_PGSIZES, +#ifdef CONFIG_INTEL_IOMMU_SVM
+ .sva_bind_gpasid= intel_svm_
Hi,
On 10/29/19 6:29 AM, Jacob Pan wrote:
Hi Baolu,
Appreciate the thorough review, comments inline.
You are welcome.
On Sat, 26 Oct 2019 10:01:19 +0800
Lu Baolu wrote:
Hi,
[...]
+* allow multiple bind calls with the same
PASID and pdev
Hi,
On 10/29/19 12:11 PM, Jacob Pan wrote:
On Tue, 29 Oct 2019 10:54:48 +0800
Lu Baolu wrote:
Hi,
On 10/29/19 6:29 AM, Jacob Pan wrote:
Hi Baolu,
Appreciate the thorough review, comments inline.
You are welcome.
On Sat, 26 Oct 2019 10:01:19 +0800
Lu Baolu wrote:
Hi
: David Woodhouse
Cc: Joerg Roedel
Cc: Ashok Raj
Cc: Jacob Pan
Cc: Kevin Tian
Signed-off-by: Lu Baolu
---
MAINTAINERS | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index cba1095547fd..86b999000fcb 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
This adds a Kconfig option INTEL_IOMMU_SCALABLE_MODE_ON to make
it easier for distributions to enable or disable the Intel IOMMU
scalable mode during kernel build.
Signed-off-by: Lu Baolu
---
drivers/iommu/Kconfig | 10 ++
drivers/iommu/intel-iommu.c | 5 +
2 files changed
Hi Christoph,
On 11/7/19 5:34 PM, Christoph Hellwig wrote:
On Wed, Nov 06, 2019 at 01:11:30PM +0800, Lu Baolu wrote:
This adds a Kconfig option INTEL_IOMMU_SCALABLE_MODE_ON to make
it easier for distributions to enable or disable the Intel IOMMU
scalable mode during kernel build.
Signed
Hi,
On 11/8/19 4:59 AM, Deepa Dinamani wrote:
The intel-iommu driver assumes that the iommu state is
cleaned up at the start of the new kernel.
But, when we try to kexec boot something other than the
Linux kernel, the cleanup cannot be relied upon.
Hence, cleanup before we go down for reboot.
K
Hi,
On 11/8/19 5:27 AM, Deepa Dinamani wrote:
On Thu, Nov 7, 2019 at 12:59 PM Deepa Dinamani wrote:
+static void intel_iommu_shutdown(void)
+ if (no_iommu || dmar_disabled)
+ return;
This check is actually not required here, as the handler is only
installed after these ha
Hi,
On 11/9/19 6:28 AM, Deepa Dinamani wrote:
+ x86_platform.iommu_shutdown = intel_iommu_shutdown;
How about moving it to detect_intel_iommu() in drivers/iommu/dmar.c? And
Ok, makes sense to move it along with the init handler.
make sure that it's included with CONFIG_X86_64.
You me
laid out at offset 52.
Fixes: 0f725561e1684 ("iommu/vt-d: Add definitions for PFSID")
Signed-off-by: Eric Auger
Please cc this to stable as well.
Cc: sta...@vger.kernel.org # v4.19+
Good catch!
Acked-by: Lu Baolu
Best regards,
baolu
---
include/linux/intel-iommu.h | 6 -
This adds Kconfig option INTEL_IOMMU_SCALABLE_MODE_DEFAULT_ON
to make it easier for distributions to enable or disable the
Intel IOMMU scalable mode by default during kernel build.
Signed-off-by: Lu Baolu
---
drivers/iommu/Kconfig | 9 +
drivers/iommu/intel-iommu.c | 7 ++-
2
Hi,
On 11/9/19 11:59 AM, Qian Cai wrote:
On Nov 8, 2019, at 10:40 PM, Lu Baolu wrote:
This adds Kconfig option INTEL_IOMMU_SCALABLE_MODE_DEFAULT_ON
to make it easier for distributions to enable or disable the
Intel IOMMU scalable mode by default during kernel build.
Signed-off-by: Lu
Hi,
On 11/11/19 1:27 AM, Deepa Dinamani wrote:
The intel-iommu driver assumes that the iommu state is
cleaned up at the start of the new kernel.
But, when we try to kexec boot something other than the
Linux kernel, the cleanup cannot be relied upon.
Hence, cleanup before we go down for reboot.
Hi,
On 11/11/19 10:00 AM, Qian Cai wrote:
On Nov 10, 2019, at 8:30 PM, Lu Baolu wrote:
How about "pasid based multiple stages DMA translation"?
It is better but I am still not sure how developers should select it or not
when asking. Ideally, should it mention pros and cons o
inamani
This patch looks good to me.
Acked-by: Lu Baolu
Best regards,
baolu
---
Changes since v1:
* move shutdown registration to iommu detection
drivers/iommu/dmar.c| 5 -
drivers/iommu/intel-iommu.c | 20
include/linux/dmar.h| 2 ++
3 fi
Hi,
On 11/11/19 11:21 AM, Deepa Dinamani wrote:
On Sun, Nov 10, 2019 at 5:35 PM Lu Baolu wrote:
Hi,
On 11/11/19 1:27 AM, Deepa Dinamani wrote:
The intel-iommu driver assumes that the iommu state is
cleaned up at the start of the new kernel.
But, when we try to kexec boot something other
Hi,
On 11/11/19 10:58 AM, Qian Cai wrote:
On Nov 8, 2019, at 10:43 PM, Lu Baolu wrote:
+config INTEL_IOMMU_SCALABLE_MODE_DEFAULT_ON
+prompt "Enable Intel IOMMU scalable mode by default"
+depends on INTEL_IOMMU
+help
+ Selecting this option will enable the scalab
Hi,
On 11/11/19 10:05 PM, Qian Cai wrote:
On Nov 11, 2019, at 12:23 AM, Lu Baolu wrote:
The scalable mode is defined in VT-d 3.0. The scalable mode capability
could be checked by reading /sys/devices/virtual/iommu/dmar*/intel-
iommu/ecap. It's currently not friendly for reading. You
This adds Kconfig option INTEL_IOMMU_SCALABLE_MODE_DEFAULT_ON
to make it easier for distributions to enable or disable the
Intel IOMMU scalable mode by default during kernel build.
Signed-off-by: Lu Baolu
---
drivers/iommu/Kconfig | 12
drivers/iommu/intel-iommu.c | 7
Hi Christoph,
On 11/12/19 3:16 PM, Christoph Hellwig wrote:
On Fri, Jul 26, 2019 at 09:56:51AM +0800, Lu Baolu wrote:
I think current code doesn't do the right thing. The user asks the iommu
driver to use identity domain for a device, but the driver force it back
to DMA domain because o
Hi Christoph,
On 11/13/19 5:53 PM, Christoph Hellwig wrote:
On Wed, Nov 13, 2019 at 08:03:12AM +0100, Christoph Hellwig wrote:
Indeed. And one idea would be to lift the code in the powerpc
dma_iommu_ops that check a flag and use the direct ops to the generic
dma code and a flag in struct devic
Merge device tlb invalidation into iommu->flush.dev_tlb_inv.
Signed-off-by: Lu Baolu
---
drivers/iommu/dmar.c| 23 ---
drivers/iommu/intel-iommu.c | 31 +--
drivers/iommu/intel-pasid.c | 3 ++-
include/linux/intel-iommu.h | 2 --
4 fi
(section 6.5) so that
people are easy to look up them in the spec.
Signed-off-by: Lu Baolu
---
drivers/iommu/dmar.c| 38
drivers/iommu/intel-iommu.c | 118 ++--
include/linux/intel-iommu.h | 34 ---
3 files changed, 98 insertions
Merge pasid cache invalidation into iommu->flush.pc_inv.
Signed-off-by: Lu Baolu
---
drivers/iommu/intel-iommu.c | 13 +
drivers/iommu/intel-pasid.c | 18 ++
include/linux/intel-iommu.h | 3 +++
3 files changed, 18 insertions(+), 16 deletions(-)
diff --gi
Merge pasid-based device tlb invalidation into iommu->flush.p_dev_tlb_inv.
Signed-off-by: Lu Baolu
---
drivers/iommu/intel-iommu.c | 41 +
drivers/iommu/intel-svm.c | 33 ++---
2 files changed, 47 insertions(+), 27 deletions(-)
d
Merge pasid-based tlb invalidation into iommu->flush.p_iotlb_inv.
Signed-off-by: Lu Baolu
---
drivers/iommu/intel-iommu.c | 43 +
drivers/iommu/intel-pasid.c | 18 ++--
drivers/iommu/intel-svm.c | 23 +++-
3 files changed,
according to the spec section 6.5
so that people are easy to look up them in the spec.
Best regards,
Lu Baolu
Lu Baolu (5):
iommu/vt-d: Extend iommu_flush for scalable mode
iommu/vt-d: Consolidate pasid cache invalidation
iommu/vt-d: Consolidate device tlb invalidation
iommu/vt-d
r-domain page table abstraction, which makes the page table
difference transparent to various map/unmap APIs. The later part
applies the first level page table for IOVA translation unless the
DOMAIN_ATTR_NESTING domain attribution has been set, which indicates
nested mode in use.
Based-on-idea-by: A
So that it could be used in other source files as well.
Signed-off-by: Lu Baolu
---
drivers/iommu/intel-iommu.c | 7 ---
include/linux/intel-iommu.h | 7 +++
2 files changed, 7 insertions(+), 7 deletions(-)
diff --git a/drivers/iommu/intel-iommu.c b/drivers/iommu/intel-iommu.c
index
This applies per domain page table ops to various domain
mapping and unmapping interfaces.
Cc: Ashok Raj
Cc: Jacob Pan
Cc: Kevin Tian
Signed-off-by: Lu Baolu
---
drivers/iommu/intel-iommu.c | 118
1 file changed, 52 insertions(+), 66 deletions(-)
diff
page table, while the second level page
table keeps compatible with previous formats.
This abstracts the page tables used in Intel IOMMU driver
by defining a per domain page table ops structure which
contains callbacks for various page table operations.
Signed-off-by: Lu Baolu
---
include/linux
This checks whether a domain should use first level page table
for map/unmap. And if so, we should attach the domain to the
device in first level translation mode.
Cc: Ashok Raj
Cc: Jacob Pan
Cc: Kevin Tian
Cc: Liu Yi L
Cc: Yi Sun
Cc: Sanjay Kumar
Signed-off-by: Lu Baolu
---
drivers/iommu
This adds functions to manipulate first level page tables
which could be used by a scalale mode capable IOMMU unit.
Cc: Ashok Raj
Cc: Jacob Pan
Cc: Kevin Tian
Cc: Liu Yi L
Cc: Yi Sun
Signed-off-by: Lu Baolu
---
drivers/iommu/Makefile | 2 +-
drivers/iommu/intel-iommu.c
nested mode, otherwise failure.
Cc: Ashok Raj
Cc: Jacob Pan
Cc: Kevin Tian
Cc: Liu Yi L
Signed-off-by: Yi Sun
Signed-off-by: Lu Baolu
---
drivers/iommu/intel-iommu.c | 56 +
1 file changed, 56 insertions(+)
diff --git a/drivers/iommu/intel-iommu.c b
This adds the implementation of page table callbacks for
the first level page table.
Cc: Ashok Raj
Cc: Jacob Pan
Cc: Kevin Tian
Cc: Liu Yi L
Cc: Yi Sun
Signed-off-by: Lu Baolu
---
drivers/iommu/intel-iommu.c | 56 +
1 file changed, 56 insertions(+)
diff
This adds the implementation of page table callbacks for
the second level page table.
Cc: Ashok Raj
Cc: Jacob Pan
Cc: Kevin Tian
Cc: Liu Yi L
Cc: Yi Sun
Signed-off-by: Lu Baolu
---
drivers/iommu/intel-iommu.c | 81 +
1 file changed, 81 insertions
Hi,
On 12/2/19 9:46 AM, Anand Misra wrote:
Hello:
I'm in process of adding iommu support in my driver for a PCIe device.
The device doesn't publish ACS/ATS via its config space. I've following
config:
Linux cmdline: "intel-iommu=on iommu=pt
vfio_iommu_type1.allow_unsafe_interrupts=1 pcie_a
Hi,
On 12/2/19 2:34 PM, Jerry Snitselaar wrote:
We are seeing DMAR PTE read access not set errors when booting a
kernel with default passthrough, both with a test kernel and with
a 5.4.0 kernel. Previously we would see a number of identity mappings
being set related to the rmrrs, and now they ar
Hi,
On 12/3/19 12:13 AM, Jerry Snitselaar wrote:
On Mon Dec 02 19, Jerry Snitselaar wrote:
On Mon Dec 02 19, Lu Baolu wrote:
Hi,
On 12/2/19 2:34 PM, Jerry Snitselaar wrote:
We are seeing DMAR PTE read access not set errors when booting a
kernel with default passthrough, both with a test
Hi Jacob,
Thanks for reviewing it.
On 12/3/19 4:19 AM, Jacob Pan wrote:
On Thu, 28 Nov 2019 10:25:42 +0800
Lu Baolu wrote:
Intel VT-d in scalable mode supports two types of page talbes
tables
Got it, thanks!
for DMA translation: the first level page table and the second
level page
Hi,
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 the
Hi Jacob,
On 12/3/19 4:02 AM, Jacob Pan wrote:
On Fri, 22 Nov 2019 11:04:44 +0800
Lu Baolu wrote:
Intel VT-d 3.0 introduces more caches and interfaces for software to
flush when it runs in the scalable mode. Currently various cache flush
helpers are scattered around. This consolidates them
Hi,
On 12/3/19 5:56 PM, Jerry Snitselaar wrote:
On Tue Dec 03 19, Lu Baolu wrote:
Hi,
On 12/3/19 12:13 AM, Jerry Snitselaar wrote:
On Mon Dec 02 19, Jerry Snitselaar wrote:
On Mon Dec 02 19, Lu Baolu wrote:
Hi,
On 12/2/19 2:34 PM, Jerry Snitselaar wrote:
We are seeing DMAR PTE read
Hi David,
On 12/3/19 4:49 PM, David Woodhouse wrote:
On Fri, 2019-11-22 at 11:04 +0800, Lu Baolu wrote:
Intel VT-d 3.0 introduces more caches and interfaces for software to
flush when it runs in the scalable mode. Currently various cache flush
helpers are scattered around. This consolidates
Hi Jacob,
On 12/4/19 12:50 AM, Jacob Pan wrote:
On Tue, 3 Dec 2019 10:44:45 +0800
Lu Baolu wrote:
Hi Jacob,
On 12/3/19 4:02 AM, Jacob Pan wrote:
On Fri, 22 Nov 2019 11:04:44 +0800
Lu Baolu wrote:
Intel VT-d 3.0 introduces more caches and interfaces for software
to flush when it runs
Hi,
On 12/4/19 3:22 AM, AM wrote:
Hi Lu Baolu,
I tried kernel 4.18.0-147.6.el8.x86_64+debug and used the following API
sequence for mapping multiple hugepages:
get_user_pages_fast()
sg_alloc_table_from_pages()
// also tried sg_alloc_table() w/ sg_set_page() using 1GB size for each
entry
-iommu.c | 4 +-
drivers/iommu/intel-svm.c| 4 +-
drivers/iommu/intel_irq_remapping.c | 2 +-
For changes in drivers/iommu/intel*.c,
Reviewed-by: Lu Baolu
Best regards,
baolu
drivers/net/ethernet/amd/xgbe/xgbe-ethtool.c | 4 +-
drivers/net
Hi,
On 12/5/19 4:53 AM, Jerry Snitselaar wrote:
Attaching console output (can't get to a point to actually log in) and
config that is used to build that kernel.
[...]
[ 21.969477] pci :00:00.0: Adding to iommu group 0
[ 21.971390] pci :00:01.0: Adding to iommu group 1
[ 21.973173
Hi,
On 12/5/19 10:25 AM, Jerry Snitselaar wrote:
It seems that iommu pci bus probe didn't enumerate device [01:00.2] and
[02:00.0], the corresponding context entries were not setup. Hence dma
fault generated when devices access the memory.
Do these two devices show in "lspci" output? How do th
Hi,
On 12/5/19 10:53 AM, Jerry Snitselaar wrote:
On Thu Dec 05 19, Lu Baolu wrote:
Hi,
On 12/5/19 10:25 AM, Jerry Snitselaar wrote:
It seems that iommu pci bus probe didn't enumerate device [01:00.2] and
[02:00.0], the corresponding context entries were not setup. Hence dma
fault gene
Hi Jerry,
On 12/6/19 3:24 PM, Jerry Snitselaar wrote:
On Fri Dec 06 19, Lu Baolu wrote:
[snip]
Can you please try below change? Let's check whether the afending
address has been mapped for device 01.00.2.
$ git diff
diff --git a/drivers/iommu/iommu.c b/drivers/iommu/iommu.c
Hi Jerry,
On 12/6/19 3:24 PM, Jerry Snitselaar wrote:
On Fri Dec 06 19, Lu Baolu wrote:
[snip]
Can you please try below change? Let's check whether the afending
address has been mapped for device 01.00.2.
$ git diff
diff --git a/drivers/iommu/iommu.c b/drivers/iommu/iommu.c
Hi,
On 12/7/19 10:41 AM, Jerry Snitselaar wrote:
On Fri Dec 06 19, Jerry Snitselaar wrote:
On Sat Dec 07 19, Lu Baolu wrote:
Hi Jerry,
On 12/6/19 3:24 PM, Jerry Snitselaar wrote:
On Fri Dec 06 19, Lu Baolu wrote:
[snip]
Can you please try below change? Let's check whether the afe
Hi Jacob,
This has been queued for internal test. I will forward it to Joerg if
everything goes well (probably around rc4).
Best regards,
-baolu
On 12/10/19 1:14 AM, Jacob Pan wrote:
Hi Joerg and Baolu,
Any more comments on this series? I rebased it on v5.5-rc1 without
changes.
Thanks,
Jac
Hi,
On 12/10/19 8:52 AM, Jerry Snitselaar wrote:
On Sun Dec 08 19, Lu Baolu wrote:
Hi,
On 12/7/19 10:41 AM, Jerry Snitselaar wrote:
On Fri Dec 06 19, Jerry Snitselaar wrote:
On Sat Dec 07 19, Lu Baolu wrote:
Hi Jerry,
On 12/6/19 3:24 PM, Jerry Snitselaar wrote:
On Fri Dec 06 19, Lu Baolu
Hi,
On 12/10/19 11:47 AM, Jerry Snitselaar wrote:
So the domain type is dma after 01:00.0 gets added, and when
intel_iommu_add_device is called for 01:00.2 it will go into the if
section. Since the device default domain type for 01:00.2 is dma
nothing happens in there, and it goes on to 01:00.4
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 :01:00.2: iommu_group_create_direct_map
Hi,
On 12/10/19 2:16 PM, Jerry Snitselaar wrote:
On Mon Dec 09 19, Jerry Snitselaar wrote:
On Mon Dec 09 19, 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
the
iommu_group_create_direct_mappings call to after the group default
domain is set, so the direct mappings get associated with that domain.
Cc: Joerg Roedel
Cc: Lu Baolu
This fix looks good to me.
Reviewed-by: Lu Baolu
Best regards,
baolu
Cc: iommu@lists.linux-foundation.org
Cc:
s replaced with
private")
Cc: sta...@vger.kernel.org # v5.3+
Signed-off-by: Lu Baolu
---
drivers/iommu/intel-iommu.c | 8
1 file changed, 8 deletions(-)
diff --git a/drivers/iommu/intel-iommu.c b/drivers/iommu/intel-iommu.c
index 0c8d81f56a30..b73bebea9148 100644
--- a/drivers/iommu
=0x148351000
size=4096
Signed-off-by: Lu Baolu
---
drivers/iommu/intel-iommu.c| 7 +++--
include/trace/events/intel_iommu.h | 48 ++
2 files changed, 47 insertions(+), 8 deletions(-)
diff --git a/drivers/iommu/intel-iommu.c b/drivers/iommu/intel-iommu.c
index
501 - 600 of 2572 matches
Mail list logo
