rmrr for graphic device still needs to be
reserved for BIOS or firmware use, when a device is going to be assigned
to user level? 2) if no, what's the check point, after which the rmrr is
unnecessary anymore?
Best regards,
Lu Baolu
On 5/9/19 5:14 PM, Zhang, Tina wrote:
Hi Baolu,
+Xiong
I
Hi Daniel,
On 5/10/19 4:34 PM, Daniel Vetter wrote:
On Fri, May 10, 2019 at 01:21:59PM +0800, Lu Baolu wrote:
Forward to i915 mailing list and post the question again so people knows
what are the key concerns.
The background is that Linux community is going to collect and report
the reserved
for the igfx ones.
Best regards,
baolu
TODO: would be nice to use the macros from include/drm/i915_pciids.h,
but can't do that with DECLARE_PCI_FIXUP_HEADER()
Cc: David Woodhouse
Cc: Lu Baolu
Cc: io...@lists.linux-foundation.org
Signed-off-by: Ville Syrjälä
---
drivers/iommu/intel/io
On 7/12/21 11:47 PM, Ville Syrjälä wrote:
On Mon, Jul 12, 2021 at 07:23:07AM +0800, Lu Baolu wrote:
On 7/10/21 12:47 AM, Ville Syrjala wrote:
From: Ville Syrjälä
While running "gem_exec_big --r single" from igt-gpu-tools on
Geminilake as soon as a 2M mapping is made I tend to get a
On 7/14/21 4:30 AM, Ville Syrjälä wrote:
On Tue, Jul 13, 2021 at 09:34:09AM +0800, Lu Baolu wrote:
On 7/12/21 11:47 PM, Ville Syrjälä wrote:
On Mon, Jul 12, 2021 at 07:23:07AM +0800, Lu Baolu wrote:
On 7/10/21 12:47 AM, Ville Syrjala wrote:
From: Ville Syrjälä
While running "gem_exe
On 2020/3/20 14:30, Tom Murphy wrote:
Could we merge patch 1-3 from this series? it just cleans up weird
code and merging these patches will cover some of the work needed to
move the intel iommu driver to the dma-iommu api in the future.
Can you please take a look at this patch series?
https:/
ers/iommu/intel/iommu.c| 18 +-
For changes in VT-d driver,
Reviewed-by: Lu Baolu
Best regards,
baolu
2 files changed, 17 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/i915/selftests/mock_gem_device.c
b/drivers/gpu/drm/i915/selfte
Hi Tvrtko,
On 9/14/20 4:04 PM, Tvrtko Ursulin wrote:
Hi,
On 12/09/2020 04:21, Lu Baolu wrote:
Tom Murphy has almost done all the work. His latest patch series was
posted here.
https://lore.kernel.org/linux-iommu/20200903201839.7327-1-murph...@tcd.ie/
Thanks a lot!
This series is a follow
Hi Logan,
On 2020/9/19 4:47, Logan Gunthorpe wrote:
Hi Lu,
On 2020-09-11 9:21 p.m., Lu Baolu wrote:
Tom Murphy has almost done all the work. His latest patch series was
posted here.
https://lore.kernel.org/linux-iommu/20200903201839.7327-1-murph...@tcd.ie/
Thanks a lot!
This series is a
Hi Logan,
On 9/21/20 11:48 PM, Logan Gunthorpe wrote:
On 2020-09-20 12:36 a.m., Lu Baolu wrote:
Hi Logan,
On 2020/9/19 4:47, Logan Gunthorpe wrote:
Hi Lu,
On 2020-09-11 9:21 p.m., Lu Baolu wrote:
Tom Murphy has almost done all the work. His latest patch series was
posted here.
https
On 9/22/20 7:05 PM, Robin Murphy wrote:
With the previous version of the series I hit a problem on Ivybridge
where apparently the dma engine width is not respected. At least
that is my layman interpretation of the errors. From the older thread:
<3> [209.526605] DMAR: intel_iommu_map: iommu wid
Hi Tvrtko,
On 9/15/20 4:31 PM, Tvrtko Ursulin wrote:
With the previous version of the series I hit a problem on Ivybridge
where apparently the dma engine width is not respected. At least that
is my layman interpretation of the errors. From the older thread:
<3> [209.526605] DMAR: intel_iommu_
From: Tom Murphy
Allow the dma-iommu api to use bounce buffers for untrusted devices.
This is a copy of the intel bounce buffer code.
Signed-off-by: Tom Murphy
Co-developed-by: Lu Baolu
Signed-off-by: Lu Baolu
---
drivers/iommu/dma-iommu.c | 163 +++---
1
...@linux.intel.com/
There aren't any other changes.
Please help to test and review.
Best regards,
baolu
Lu Baolu (3):
iommu: Add quirk for Intel graphic devices in map_sg
iommu/vt-d: Update domain geometry in iommu_ops.at(de)tach_dev
iommu/vt-d: Cleanup after converting to dma-iommu ops
Tom M
Some cleanups after converting the driver to use dma-iommu ops.
- Remove nobounce option;
- Cleanup and simplify the path in domain mapping.
Signed-off-by: Lu Baolu
---
.../admin-guide/kernel-parameters.txt | 5 --
drivers/iommu/intel/iommu.c | 90
table pages can be freed. This way we can still batch
ioTLB free operations and handle the freelists.
Signed-off-by: Tom Murphy
Signed-off-by: Lu Baolu
---
drivers/iommu/dma-iommu.c | 29 +--
drivers/iommu/intel/iommu.c | 55 -
include/linux
The iommu-dma constrains IOVA allocation based on the domain geometry
that the driver reports. Update domain geometry everytime a domain is
attached to or detached from a device.
Signed-off-by: Lu Baolu
---
drivers/iommu/intel/iommu.c | 16 ++--
1 file changed, 14 insertions(+), 2
From: Tom Murphy
Convert the intel iommu driver to the dma-iommu api. Remove the iova
handling and reserve region code from the intel iommu driver.
Signed-off-by: Tom Murphy
Signed-off-by: Lu Baolu
---
drivers/iommu/intel/Kconfig | 1 +
drivers/iommu/intel/iommu.c | 742
stead depends on the previous behaviour of the Intel iommu driver
which would return the same number of elements in the output list as in
the input list.
Signed-off-by: Tom Murphy
Signed-off-by: Lu Baolu
---
drivers/iommu/dma-iommu.c | 27 +++
1 file changed, 27 inser
From: Tom Murphy
Add a iommu_dma_free_cpu_cached_iovas function to allow drivers which
use the dma-iommu ops to free cached cpu iovas.
Signed-off-by: Tom Murphy
Signed-off-by: Lu Baolu
---
drivers/iommu/dma-iommu.c | 9 +
include/linux/dma-iommu.h | 8
2 files changed, 17
Hi Tvrtko,
On 9/28/20 5:44 PM, Tvrtko Ursulin wrote:
On 27/09/2020 07:34, Lu Baolu wrote:
Hi,
The previous post of this series could be found here.
https://lore.kernel.org/linux-iommu/20200912032200.11489-1-baolu...@linux.intel.com/
This version introduce a new patch [4/7] to fix an
Hi Joerg,
On 2020/10/1 20:17, Joerg Roedel wrote:
Hi Baolu,
On Tue, Sep 29, 2020 at 08:11:35AM +0800, Lu Baolu wrote:
I have no preference. It depends on which patch goes first. Let the
maintainers help here.
No preference on my side, except that it is too late for this now to
make it into
Hi Tvrtko,
On 10/12/20 4:44 PM, Tvrtko Ursulin wrote:
On 29/09/2020 01:11, Lu Baolu wrote:
Hi Tvrtko,
On 9/28/20 5:44 PM, Tvrtko Ursulin wrote:
On 27/09/2020 07:34, Lu Baolu wrote:
Hi,
The previous post of this series could be found here.
https://lore.kernel.org/linux-iommu
Hi Tvrtko,
On 10/12/20 4:44 PM, Tvrtko Ursulin wrote:
On 29/09/2020 01:11, Lu Baolu wrote:
Hi Tvrtko,
On 9/28/20 5:44 PM, Tvrtko Ursulin wrote:
On 27/09/2020 07:34, Lu Baolu wrote:
Hi,
The previous post of this series could be found here.
https://lore.kernel.org/linux-iommu
On 11/2/20 7:52 PM, Tvrtko Ursulin wrote:
On 02/11/2020 02:00, Lu Baolu wrote:
Hi Tvrtko,
On 10/12/20 4:44 PM, Tvrtko Ursulin wrote:
On 29/09/2020 01:11, Lu Baolu wrote:
Hi Tvrtko,
On 9/28/20 5:44 PM, Tvrtko Ursulin wrote:
On 27/09/2020 07:34, Lu Baolu wrote:
Hi,
The previous post of
On 2020/11/3 18:54, Joerg Roedel wrote:
Hi,
On Tue, Nov 03, 2020 at 11:58:26AM +0200, Joonas Lahtinen wrote:
Would that work for you? We intend to send the feature pull requests
to DRM for 5.11 in the upcoming weeks.
For the IOMMU side it is best to include the workaround for now. When
the DR
status.
Signed-off-by: Tvrtko Ursulin
Cc: Lu Baolu
---
Baolu, is my understanding here correct? Maybe I am confused by both
intel_iommu_gfx_mapped and dmar_map_gfx being globals in the intel_iommu
driver. But it certainly appears the setup can assign some iommu ops (and
assign the discrete i915 to iommu
On 2021/11/10 1:35, Tvrtko Ursulin wrote:
On 09/11/2021 17:19, Lucas De Marchi wrote:
On Tue, Nov 09, 2021 at 12:17:59PM +, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin
On igfx + dgfx setups, it appears that intel_iommu=igfx_off option only
disables the igfx iommu. Stop relying on global i
On 2021/11/10 17:30, Tvrtko Ursulin wrote:
On 10/11/2021 07:12, Lu Baolu wrote:
Hi Tvrtko,
On 2021/11/9 20:17, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin
On igfx + dgfx setups, it appears that intel_iommu=igfx_off option only
disables the igfx iommu. Stop relying on global
On 2021/11/10 17:35, Tvrtko Ursulin wrote:
On 10/11/2021 07:25, Lu Baolu wrote:
On 2021/11/10 1:35, Tvrtko Ursulin wrote:
On 09/11/2021 17:19, Lucas De Marchi wrote:
On Tue, Nov 09, 2021 at 12:17:59PM +, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin
On igfx + dgfx setups, it appears
On 2021/11/10 20:08, Tvrtko Ursulin wrote:
On 10/11/2021 12:04, Lu Baolu wrote:
On 2021/11/10 17:30, Tvrtko Ursulin wrote:
On 10/11/2021 07:12, Lu Baolu wrote:
Hi Tvrtko,
On 2021/11/9 20:17, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin
On igfx + dgfx setups, it appears that intel_iommu
On 11/11/21 11:06 PM, Tvrtko Ursulin wrote:
On 10/11/2021 12:35, Lu Baolu wrote:
On 2021/11/10 20:08, Tvrtko Ursulin wrote:
On 10/11/2021 12:04, Lu Baolu wrote:
On 2021/11/10 17:30, Tvrtko Ursulin wrote:
On 10/11/2021 07:12, Lu Baolu wrote:
Hi Tvrtko,
On 2021/11/9 20:17, Tvrtko Ursulin
On 11/11/21 11:18 PM, Tvrtko Ursulin wrote:
On 10/11/2021 14:37, Robin Murphy wrote:
On 2021-11-10 14:11, Tvrtko Ursulin wrote:
On 10/11/2021 12:35, Lu Baolu wrote:
On 2021/11/10 20:08, Tvrtko Ursulin wrote:
On 10/11/2021 12:04, Lu Baolu wrote:
On 2021/11/10 17:30, Tvrtko Ursulin wrote
ange
in the future.
With device_iommu_mapped() replaced,
Reviewed-by: Lu Baolu
Best regards,
baolu
phic dedicated IOMMU. Hence, there is
really no good reason to keep this config option.
Suggested-by: Kevin Tian
Signed-off-by: Lu Baolu
Reviewed-by: Kevin Tian
---
drivers/iommu/intel/iommu.c | 4
drivers/iommu/intel/Kconfig | 11 ---
2 files changed, 15 deletions(-)
Change log:
but
commit ("iommu/vt-d: Delegate the dma domain to upper layer")
and adjust the title as "iommu/vt-d: Handle 36bit addressing for x86-32"
with above two changes,
Acked-by: Lu Baolu
Best regards,
baolu
the error looks older.
Fixes: fa954e683178 ("iommu/vt-d: Delegate th
://linuxplumbersconf.org/event/7/contributions/846/
As far as I can remember everyone seemed happy with that solution. I
won't be working on this though as I don't have any more time to
dedicate to this. It seems Lu Baolu will take over this.
I'm absolutely again passing a flag. T
On 2020/9/8 14:23, Christoph Hellwig wrote:
On Tue, Sep 08, 2020 at 02:04:53PM +0800, Lu Baolu wrote:
Do you mind telling where can I find Marek's series?
[PATCH v10 00/30] DRM: fix struct sg_table nents vs. orig_nents misuse
on various lists including the iommu one.
Get it. Than
Hi Christoph,
On 9/8/20 2:23 PM, Christoph Hellwig wrote:
On Tue, Sep 08, 2020 at 02:04:53PM +0800, Lu Baolu wrote:
Do you mind telling where can I find Marek's series?
[PATCH v10 00/30] DRM: fix struct sg_table nents vs. orig_nents misuse
on various lists including the iommu one.
On 2020/9/9 15:06, Christoph Hellwig wrote:
On Wed, Sep 09, 2020 at 09:43:09AM +0800, Lu Baolu wrote:
+ /*
+* The Intel graphic device driver is used to assume that the
returned
+* sg list is not combound. This blocks the efforts of converting
the
This adds pointless
table pages can be freed. This way we can still batch
ioTLB free operations and handle the freelists.
Signed-off-by: Tom Murphy
Signed-off-by: Lu Baolu
---
drivers/iommu/dma-iommu.c | 30 ++--
drivers/iommu/intel/iommu.c | 55 -
include
er.
2. Fix several bugs in patch "iommu: Allow the dma-iommu api to use
bounce buffers" to make the bounce buffer work for untrusted devices.
3. Several cleanups in iommu/vt-d driver after the conversion.
Please review and test.
Best regards,
baolu
Lu Baolu (2):
iommu: Add quirk fo
stead depends on the previous behaviour of the Intel iommu driver
which would return the same number of elements in the output list as in
the input list.
Signed-off-by: Tom Murphy
Signed-off-by: Lu Baolu
---
drivers/iommu/dma-iommu.c | 27 +++
1 file changed, 27 inser
Some cleanups after converting the driver to use dma-iommu ops.
- Remove nobounce option;
- Cleanup and simplify the path in domain mapping.
Signed-off-by: Lu Baolu
---
.../admin-guide/kernel-parameters.txt | 5 --
drivers/iommu/intel/iommu.c | 90
From: Tom Murphy
Allow the dma-iommu api to use bounce buffers for untrusted devices.
This is a copy of the intel bounce buffer code.
Signed-off-by: Tom Murphy
Co-developed-by: Lu Baolu
Signed-off-by: Lu Baolu
---
drivers/iommu/dma-iommu.c | 163 +++---
1
From: Tom Murphy
Add a iommu_dma_free_cpu_cached_iovas function to allow drivers which
use the dma-iommu ops to free cached cpu iovas.
Signed-off-by: Tom Murphy
Signed-off-by: Lu Baolu
---
drivers/iommu/dma-iommu.c | 9 +
include/linux/dma-iommu.h | 8
2 files changed, 17
From: Tom Murphy
Convert the intel iommu driver to the dma-iommu api. Remove the iova
handling and reserve region code from the intel iommu driver.
Signed-off-by: Tom Murphy
Signed-off-by: Lu Baolu
---
drivers/iommu/intel/Kconfig | 1 +
drivers/iommu/intel/iommu.c | 742
and igfx_off can
be made independent.
Fixes: 4b8d18c0c986 ("iommu/vt-d: Remove INTEL_IOMMU_BROKEN_GFX_WA")
Signed-off-by: Lu Baolu
---
drivers/iommu/intel/iommu.c | 19 ++-
1 file changed, 6 insertions(+), 13 deletions(-)
diff --git a/drivers/iommu/intel/iommu.c b/drivers/iommu/intel/iommu.
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
Hi,
On 12/21/19 11:03 PM, Tom Murphy wrote:
@@ -5618,9 +5583,13 @@ static int intel_iommu_add_device(struct device *dev)
struct iommu_domain *domain;
struct intel_iommu *iommu;
struct iommu_group *group;
+ u64 dma_mask = *dev->dma_mask;
u8 bus, devfn;
issing
IOMMU bus detach on device unplug operation could be added.
Which kernel version are you testing with? Does it contain below commit?
commit 458b7c8e0dde12d140e3472b80919cbb9ae793f4
Author: Lu Baolu
Date: Thu Aug 1 11:14:58 2019 +0800
iommu/vt-d: Detach domain when move device
Hi Janusz,
On 8/26/19 4:15 PM, Janusz Krzysztofik wrote:
Hi Lu,
On Friday, August 23, 2019 3:51:11 AM CEST Lu Baolu wrote:
Hi,
On 8/22/19 10:29 PM, Janusz Krzysztofik wrote:
When a perfectly working i915 device is hot unplugged (via sysfs) and
hot re-plugged again, its dev->archdata.io
Hi Janusz,
On 8/27/19 5:35 PM, Janusz Krzysztofik wrote:
Hi Lu,
On Monday, August 26, 2019 10:29:12 AM CEST Lu Baolu wrote:
Hi Janusz,
On 8/26/19 4:15 PM, Janusz Krzysztofik wrote:
Hi Lu,
On Friday, August 23, 2019 3:51:11 AM CEST Lu Baolu wrote:
Hi,
On 8/22/19 10:29 PM, Janusz
Hi Janusz,
On 8/28/19 10:17 PM, Janusz Krzysztofik wrote:
We should avoid kernel panic when a intel_unmap() is called against
a non-existent domain.
Does that mean you suggest to replace
BUG_ON(!domain);
with something like
if (WARN_ON(!domain))
return;
and to no
Hi,
On 8/29/19 3:58 PM, Janusz Krzysztofik wrote:
Hi Baolu,
On Thursday, August 29, 2019 3:43:31 AM CEST Lu Baolu wrote:
Hi Janusz,
On 8/28/19 10:17 PM, Janusz Krzysztofik wrote:
We should avoid kernel panic when a intel_unmap() is called against
a non-existent domain.
Does that mean you
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 solutions.
Then reverting 458b7c8e0dde and applying this patch still resolves the issue
for me. No errors appear when mappings are unmap
when we should be pushing for it to
be always enabled. Quirk away Broadwell and remove the rotten apple.
References: https://bugs.freedesktop.org/show_bug.cgi?id=89360
Signed-off-by: Chris Wilson
Cc: Lu Baolu
This patch looks good to me.
Reviewed-by: Lu Baolu
-baolu
Cc: Martin Peres
Cc
Hi Joerg,
The graphic guys are looking forward to having this in 4.18.
Is it possible to take it in the following rcs?
Best regards,
Lu Baolu
On 07/08/2018 02:23 PM, Lu Baolu wrote:
> This reverts commit ab96746aaa344fb720a198245a837e266fad3b62.
>
> The commit ab96746aaa34 ("iom
59 matches
Mail list logo
