From: Joerg Roedel
Consolidate the allocation of the domain page-table in one place.
Signed-off-by: Joerg Roedel
---
drivers/iommu/amd/iommu.c | 48 ++-
1 file changed, 22 insertions(+), 26 deletions(-)
diff --git a/drivers/iommu/amd/iommu.c b/drivers
hes are runtime-tested, including device-assignment.
Please review.
Regards,
Joerg
Joerg Roedel (10):
iommu/amd: Move AMD IOMMU driver to a subdirectory
iommu/amd: Unexport get_dev_data()
iommu/amd: Let free_pagetable() not rely on domain->pt_root
iommu/amd: Allocate page
From: Joerg Roedel
Merge the allocation code paths of DMA and UNMANAGED domains and
remove code duplication.
Signed-off-by: Joerg Roedel
---
drivers/iommu/amd/iommu.c | 116 +-
1 file changed, 27 insertions(+), 89 deletions(-)
diff --git a/drivers/iommu
From: Joerg Roedel
Checking the return value of get_device_id() in a code-path which has
already done check_device() is not needed, as check_device() does the
same check and bails out if it fails.
Signed-off-by: Joerg Roedel
---
drivers/iommu/amd/iommu.c | 13 ++---
1 file changed, 2
From: Joerg Roedel
Use 'struct domain_pgtable' instead to free_pagetable(). This solves
the problem that amd_iommu_domain_direct_map() needs to restore
domain->pt_root after the device table has been updated just to make
free_pagetable release the domain page-table.
Signed-off-by: Joerg Roe
From: Joerg Roedel
This function is internal to the AMD IOMMU driver and only exported
because the amd_iommu_v2 modules calls it. But the reason it is called
from there could better be handled by amd_iommu_is_attach_deferred().
So unexport get_dev_data() and use amd_iommu_is_attach_deferred
From: Joerg Roedel
This is covered by IOMMU_DOMAIN_DMA from the IOMMU core code already,
so remove it.
Signed-off-by: Joerg Roedel
---
drivers/iommu/amd/iommu.c | 24 +++-
1 file changed, 7 insertions(+), 17 deletions(-)
diff --git a/drivers/iommu/amd/iommu.c b/drivers
On Thu, May 21, 2020 at 11:49:06AM -0700, Andrew Morton wrote:
> I'll assume that Joerg will handle this fix?
Yes, I will when it turns out necessary.
Regards,
Joerg
On Thu, May 21, 2020 at 06:39:44PM +0100, Will Deacon wrote:
> Hi Joerg,
>
> Please pull these Arm SMMU updates for 5.8. The branch is based on your
> 'core' branch from a little while ago.
>
> Summary in the tag.
>
> Cheers,
>
> Will
>
> --->8
>
> The following changes since commit
On Tue, May 12, 2020 at 12:08:29PM +0800, Zhangfei Gao wrote:
> Some platform devices appear as PCI but are
> actually on the AMBA bus, and they need fixup in
> drivers/pci/quirks.c handling iommu_fwnode.
> So calling pci_fixup_final after iommu_fwnode is allocated.
>
> For example:
> Hisilicon
Hi,
On Fri, May 22, 2020 at 06:31:45PM +0530, Sai Prakash Ranjan wrote:
> diff --git a/drivers/iommu/iommu.c b/drivers/iommu/iommu.c
> index a4c2f122eb8b..05f7b77c432f 100644
> --- a/drivers/iommu/iommu.c
> +++ b/drivers/iommu/iommu.c
> @@ -1491,6 +1491,7 @@ static int
From: Joerg Roedel
The iommu_alloc_default_domain() function takes a reference to an IOMMU
group without releasing it. This causes the group to never be released,
with undefined side effects.
The function has only one call-site, which takes a group reference on
its own, so to fix this leak, do
On Wed, May 20, 2020 at 04:36:31AM +1000, Stephen Rothwell wrote:
> Maybe you meant
>
> Fixes: b0d1f8741b81 ("iommu/vt-d: Add nested translation helper function")
> Fixes: 56722a4398a3 ("iommu/vt-d: Add bind guest PASID support")
Updated, thanks.
On Thu, May 21, 2020 at 05:50:30PM -0400, Qian Cai wrote:
> The commit 6ee1b77ba3ac ("iommu/vt-d: Add svm/sva invalidate function")
> introduced a GCC warning,
>
> drivers/iommu/intel-iommu.c:5330:1: warning: 'static' is not at beginning of
> declaration [-Wold-style-declaration]
> const static
Hi Guillaume,
On Wed, May 20, 2020 at 10:54:44AM +0100, Guillaume Tucker wrote:
> Please see the bisection report below about a boot failure.
>
> Reports aren't automatically sent to the public while we're
> trialing new bisection features on kernelci.org but this one
> looks valid.
>
>
On Mon, May 18, 2020 at 03:18:28PM -0700, Andrew Morton wrote:
> It would be nice to get all this (ie, linux-next) retested before we
> send it upstream, please.
Tested these patches as in next-20200522, with three 2, 3, and 4-level
paging. On 4-level (aka 64-bit) I also re-ran the Stevens
.
Alexander Monakov (1):
iommu/amd: Fix over-read of ACPI UID from IVRS table
Joerg Roedel (1):
iommu: Fix deferred domain attachment
Raul E Rangel (1):
iommu/amd: Fix get_acpihid_device_id()
drivers/iommu/amd_iommu.c | 3 ++-
drivers/iommu/amd_iommu_init.c | 9
On Mon, May 18, 2020 at 03:18:28PM -0700, Andrew Morton wrote:
> On Sat, 16 May 2020 14:56:41 +0200 Joerg Roedel wrote:
> --- a/mm/vmalloc.c~mm-vmalloc-track-which-page-table-levels-were-modified-fix
> +++ a/mm/vmalloc.c
> @@ -309,6 +309,9 @@ int map_kernel_range_noflush
From: Joerg Roedel
The .probe_finalize() call-back of some IOMMU drivers calls into
arm_iommu_attach_device(). This function will call back into the
IOMMU core code, where it tries to take group->mutex again, resulting
in a deadlock.
As there is no reason why .probe_finalize() ne
From: Joerg Roedel
The IOMMU core code has support for deferring the attachment of a domain
to a device. This is needed in kdump kernels where the new domain must
not be attached to a device before the device driver takes it over.
When the AMD IOMMU driver got converted to use the dma-iommu
On Tue, May 19, 2020 at 03:57:44PM +0800, Yong Wu wrote:
> This patch fixes a build warning:
> drivers/iommu/mtk_iommu_v1.c: In function 'mtk_iommu_release_device':
> >> drivers/iommu/mtk_iommu_v1.c:467:25: warning: variable 'data' set but
> >> not used [-Wunused-but-set-variable]
> 467 | struct
On Tue, May 19, 2020 at 09:18:57AM +, Wei Yongjun wrote:
> In case of error, the function devm_platform_ioremap_resource() returns
> ERR_PTR() not NULL. The NULL test in the return value check must be
> replaced with IS_ERR().
>
> Fixes: 4100b8c229b3 ("iommu: Add Allwinner H6 IOMMU driver")
>
Hi,
On Mon, May 18, 2020 at 02:51:20PM +0800, Yong Wu wrote:
> below is my local patch. split "dma_attach" to attach_device and
> probe_finalize. About attach_device, Use the existed
> __iommu_attach_group instead. Then rename from the "dma_attach" to
> "probe_finalize" to do the probe_finalize
On Fri, May 15, 2020 at 04:08:43PM +0800, Yong Wu wrote:
> The MediaTek V1 IOMMU is arm32 whose default domain type is
> IOMMU_DOMAIN_UNMANAGED. Add this to satisfy the bus_iommu_probe to
> enter "probe_finalize".
>
> The iommu framework will create a iommu domain for each a device.
> But all the
On Mon, May 18, 2020 at 05:06:45PM +0800, Kai-Heng Feng wrote:
> Particularly, as soon as the spinlock is removed, the issue can be reproduced.
> Function domain_flush_complete() doesn't seem to affect the status.
>
> However, the .map_page callback was removed by be62dbf554c5
> ("iommu/amd:
On Fri, May 15, 2020 at 08:23:13PM +0100, Robin Murphy wrote:
> But that's not what this is; this is (supposed to be) the exact same "don't
> actually perform the attach yet" logic as before, just restricting it to
> default domains in the one place that it actually needs to be, so as not to
>
Hi Andrew,
On Fri, May 15, 2020 at 01:01:42PM -0700, Andrew Morton wrote:
> On Fri, 15 May 2020 16:00:18 +0200 Joerg Roedel wrote:
> Lots of collisions here with Christoph's "decruft the vmalloc API" series
> (http://lkml.kernel.org/r/20200414131348.444715-1-...@lst.de).
>
On Fri, May 15, 2020 at 05:28:53PM +0100, Robin Murphy wrote:
> On 2020-05-15 17:14, Joerg Roedel wrote:
> > diff --git a/drivers/iommu/dma-iommu.c b/drivers/iommu/dma-iommu.c
> > index ba128d1cdaee..403fda04ea98 100644
> > --- a/drivers/iommu/dma-iommu.c
> > +++
t work for its only user, the
AMD IOMMU driver, the reason is that it calls iommu_attach_device(),
which in its code-path checks for deferred attaching again and bails
out, without do the real attachment.
But below updated fix should work. Jerry, could you please test it
again?
>From 4e262dedcd36c7572312c65e6
On Fri, May 15, 2020 at 09:51:03PM +0800, Lu Baolu wrote:
> On 2020/5/15 17:45, Joerg Roedel wrote:
> > struct iommu_domain *iommu_get_dma_domain(struct device *dev)
> > {
> > - return dev->iommu_group->default_domain;
> > + struct iommu_domain *domain =
From: Joerg Roedel
These functions are not needed anymore because the vmalloc and ioremap
mappings are now synchronized when they are created or teared down.
Remove all callers and function definitions.
Signed-off-by: Joerg Roedel
Tested-by: Steven Rostedt (VMware)
Acked-by: Andy Lutomirski
From: Joerg Roedel
Implement the function to sync changes in vmalloc and ioremap ranges
to all page-tables.
Signed-off-by: Joerg Roedel
Acked-by: Andy Lutomirski
---
arch/x86/include/asm/pgtable-2level_types.h | 2 ++
arch/x86/include/asm/pgtable-3level_types.h | 2 ++
arch/x86/mm/fault.c
From: Joerg Roedel
Track at which levels in the page-table entries were modified by
vmap/vunmap. After the page-table has been modified, use that
information do decide whether the new arch_sync_kernel_mappings()
needs to be called.
Signed-off-by: Joerg Roedel
Acked-by: Andy Lutomirski
From: Joerg Roedel
Track at which levels in the page-table entries were modified by
ioremap_page_range(). After the page-table has been modified, use that
information do decide whether the new arch_sync_kernel_mappings()
needs to be called. The iounmap path re-uses vunmap(), which has
already
/
v2: https://lore.kernel.org/lkml/20200513152137.32426-1-j...@8bytes.org/
The cover-letter of v1 has more details on the motivation
for this patch-set.
Please review.
Regards,
Joerg
Joerg Roedel (7):
mm: Add functions to track page directory modifications
mm/vmalloc: Track which
From: Joerg Roedel
Implement the function to sync changes in vmalloc and ioremap ranges
to all page-tables.
Signed-off-by: Joerg Roedel
Acked-by: Andy Lutomirski
---
arch/x86/include/asm/pgtable_64_types.h | 2 ++
arch/x86/mm/init_64.c | 5 +
2 files changed, 7
From: Joerg Roedel
Remove fault handling on vmalloc areas, as the vmalloc code now takes
care of synchronizing changes to all page-tables in the system.
Signed-off-by: Joerg Roedel
Acked-by: Andy Lutomirski
---
arch/x86/include/asm/switch_to.h | 23 --
arch/x86/kernel/setup_percpu.c
From: Joerg Roedel
Add page-table allocation functions which will keep track of changed
directory entries. They are needed for new PGD, P4D, PUD, and PMD
entries and will be used in vmalloc and ioremap code to decide whether
any changes in the kernel mappings need to be synchronized between
page
On Wed, May 13, 2020 at 09:01:04AM -0700, Andy Lutomirski wrote:
> I would love to see a followup patch that preallocates the vmalloc
> region on 64-bit and compiles out pgd_list and all of the associated
> gunk.
Looked a bit into this, with pre-allocation and a few more changes all
but one users
Hi,
On Fri, May 15, 2020 at 03:44:59PM +0800, Yong Wu wrote:
> On Tue, 2020-04-14 at 15:15 +0200, Joerg Roedel wrote:
> > - return iommu_device_link(>iommu, dev);
> > + err = arm_iommu_attach_device(dev, mtk_mapping);
> > + if (err)
> > + dev_err(de
From: Joerg Roedel
The IOMMU core code has support for deferring the attachment of a domain
to a device. This is needed in kdump kernels where the new domain must
not be attached to a device before the device driver takes it over.
But this needs support from the dma-ops code too, to actually do
On Thu, May 14, 2020 at 05:36:23PM +0200, Joerg Roedel wrote:
> This commit also removes the deferred attach of the device to its new
> domain. Does the attached diff fix the problem for you?
> +static int __iommu_attach_device_no_defer(struct iommu_domai
Hi Jerry,
On Wed, May 13, 2020 at 08:18:38PM -0700, Jerry Snitselaar wrote:
> We've seen kdump failures with recent kernels (5.5, 5.6, 5.7-rc1) on
> amd systems when iommu is enabled in translation mode. In the cases so
> far there has been mpt3sas involved, but I'm also seeing io page
> faults
On Wed, May 13, 2020 at 09:01:04AM -0700, Andy Lutomirski wrote:
> Assuming the missing cleanup at the end gets done:
>
> Acked-by: Andy Lutomirski
>
> grumpily acked, anyway.
Thanks, I updated patch 7 and added your acks, will send a v3 probably
tomorrow.
Joerg
From: Joerg Roedel
A few compile warnings show up when building this driver:
CC drivers/iommu/sun50i-iommu.o
drivers/iommu/sun50i-iommu.c: In function ‘sun50i_dte_get_page_table’:
drivers/iommu/sun50i-iommu.c:486:16: warning: unused variable ‘flags’
[-Wunused-variable]
486 | unsigned
From: Joerg Roedel
Allocate zeroed memory so there is no need to memset it to 0 in the
driver.
Cc: Maxime Ripard
Signed-off-by: Joerg Roedel
---
drivers/iommu/sun50i-iommu.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/iommu/sun50i-iommu.c b/drivers/iommu
On Wed, May 13, 2020 at 11:16:14PM +0100, Guillaume Tucker wrote:
> which this time gave me:
>
> <4>[2.540558] PC is at iommu_probe_device+0x1c/0x15c
> <4>[2.545606] LR is at of_iommu_configure+0x15c/0x1c4
> <4>[2.550736] pc : []lr : []psr: a013
>
> which in turn brings
From: Joerg Roedel
Add page-table allocation functions which will keep track of changed
directory entries. They are needed for new PGD, P4D, PUD, and PMD
entries and will be used in vmalloc and ioremap code to decide whether
any changes in the kernel mappings need to be synchronized between
page
From: Joerg Roedel
These functions are not needed anymore because the vmalloc and ioremap
mappings are now synchronized when they are created or teared down.
Remove all callers and function definitions.
Tested-by: Steven Rostedt (VMware)
Signed-off-by: Joerg Roedel
---
arch/x86/mm/fault.c
From: Joerg Roedel
Track at which levels in the page-table entries were modified by
vmap/vunmap. After the page-table has been modified, use that
information do decide whether the new arch_sync_kernel_mappings()
needs to be called.
Signed-off-by: Joerg Roedel
---
include/linux/vmalloc.h | 16
-set.
Please review.
Regards,
Joerg
Joerg Roedel (7):
mm: Add functions to track page directory modifications
mm/vmalloc: Track which page-table levels were modified
mm/ioremap: Track which page-table levels were modified
x86/mm/64: Implement arch_sync_kernel_mappings()
x86/mm/32
From: Joerg Roedel
Implement the function to sync changes in vmalloc and ioremap ranges
to all page-tables.
Signed-off-by: Joerg Roedel
---
arch/x86/include/asm/pgtable_64_types.h | 2 ++
arch/x86/mm/init_64.c | 5 +
2 files changed, 7 insertions(+)
diff --git a/arch
From: Joerg Roedel
Track at which levels in the page-table entries were modified by
ioremap_page_range(). After the page-table has been modified, use that
information do decide whether the new arch_sync_kernel_mappings()
needs to be called. The iounmap path re-uses vunmap(), which has
already
From: Joerg Roedel
Implement the function to sync changes in vmalloc and ioremap ranges
to all page-tables.
Signed-off-by: Joerg Roedel
---
arch/x86/include/asm/pgtable-2level_types.h | 2 ++
arch/x86/include/asm/pgtable-3level_types.h | 2 ++
arch/x86/mm/fault.c
From: Joerg Roedel
Remove fault handling on vmalloc areas, as the vmalloc code now takes
care of synchronizing changes to all page-tables in the system.
Signed-off-by: Joerg Roedel
---
arch/x86/include/asm/switch_to.h | 23 --
arch/x86/kernel/setup_percpu.c | 6 +-
arch/x86/mm
On Wed, May 13, 2020 at 01:13:40PM +0200, Borislav Petkov wrote:
> On Tue, Apr 28, 2020 at 05:16:34PM +0200, Joerg Roedel wrote:
> > @@ -302,9 +313,13 @@ void do_boot_page_fault(struct pt_regs *regs, unsigned
> > long error_code)
> > * - User faults
> >
On Tue, May 12, 2020 at 10:17:19AM +0800, Samuel Zou wrote:
> Fix the following sparse warning:
>
> drivers/iommu/msm_iommu.c:37:1: warning: symbol 'msm_iommu_lock' was not
> declared.
>
> The msm_iommu_lock has only call site within msm_iommu.c
> It should be static
>
> Fixes: 0720d1f052dc
On Mon, May 11, 2020 at 10:33:36AM -0600, Raul E Rangel wrote:
> acpi_dev_hid_uid_match() expects a null pointer for UID if it doesn't
> exist. The acpihid_map_entry contains a char buffer for holding the
> UID. If no UID was provided in the IVRS table, this buffer will be
> zeroed. If we pass in
array is always zero-terminated. No change needed for the hid
> array, as it was already properly zero-terminated.
>
> Fixes: 2a0cb4e2d423c ("iommu/amd: Add new map for storing IVHD dev entry type
> HID")
>
> Signed-off-by: Alexander Monakov
> Cc: Joerg Roedel
> Cc: io..
Hi Marek,
On Tue, May 12, 2020 at 11:00:23AM +0200, Marek Szyprowski wrote:
> ---
> include/linux/iommu.h | 16
> 1 file changed, 16 insertions(+)
Some nits below, with those fixed:
Acked-by: Joerg Roedel
> diff --git a/include/linux/iommu.h b/include/l
On Sat, May 09, 2020 at 12:02:16AM +0200, Arnd Bergmann wrote:
> gcc warns because the only reference to ipmmu_find_group
> is inside of an #ifdef:
>
> drivers/iommu/ipmmu-vmsa.c:878:28: error: 'ipmmu_find_group' defined but not
> used [-Werror=unused-function]
>
> Change the #ifdef to an
On Fri, May 08, 2020 at 01:40:36PM +, YueHaibing wrote:
> Fixes gcc '-Wunused-but-set-variable' warning:
>
> drivers/iommu/amd_iommu.c: In function 'amd_iommu_uninit_device':
> drivers/iommu/amd_iommu.c:422:20: warning:
> variable 'iommu' set but not used [-Wunused-but-set-variable]
>
>
On Wed, May 06, 2020 at 09:59:44AM +0800, Lu Baolu wrote:
> Lu Baolu (3):
> iommu/vt-d: Allow 32bit devices to uses DMA domain
> iommu/vt-d: Allow PCI sub-hierarchy to use DMA domain
> iommu/vt-d: Apply per-device dma_ops
>
> drivers/iommu/intel-iommu.c | 396
On Fri, May 08, 2020 at 09:56:45PM -0400, Qian Cai wrote:
> The commit dce8d6964ebd ("iommu/amd: Convert to probe/release_device()
> call-backs") introduced an unused variable,
>
> drivers/iommu/amd_iommu.c: In function 'amd_iommu_uninit_device':
> drivers/iommu/amd_iommu.c:422:20: warning:
Hi Lenny,
On Tue, May 12, 2020 at 04:00:26PM -0400, Lenny Szubowicz wrote:
> Some Lenovo laptops provide an ACPI DMAR RMRR that identifies the memory
> range that the kernel should open up for permissable DMA access
> for this purpose. Unfortunately, the PCI device that performs these
> DMA
On Tue, May 12, 2020 at 08:11:57PM +0200, Borislav Petkov wrote:
> > +# sev-es.c inludes generated $(objtree)/arch/x86/lib/inat-tables.c
>
> "includes"
>
> > +CFLAGS_sev-es.o += -I$(objtree)/arch/x86/lib/
>
> Does it?
>
> I see
>
> #include "../../lib/inat.c"
> #include
Hi Guillaume,
thanks for the report!
On Tue, May 12, 2020 at 07:05:13AM +0100, Guillaume Tucker wrote:
> > Summary:
> > Start: 4b20e7462caa6 Add linux-next specific files for 20200511
> > Plain log:
> >
On Mon, May 11, 2020 at 12:36:19PM -0700, Andy Lutomirski wrote:
> I’m guessing the right solution is either your series or your series
> plus preallocation on 64-bit. I’m just grumpy about it...
Okay, so we can do the pre-allocation when it turns out the pgd_list
lock-times become a problem on
On Mon, May 11, 2020 at 09:43:11AM -0400, Lenny Szubowicz wrote:
> I suspect that you have TPM 2.x functionality enabled in the BIOS/firmware.
>
> Unless you are actually using the TPM, try setting it to TPM 1.2 mode.
> I've seen an incompatiblity on other Lenovo laptops between using the
>
On Mon, May 11, 2020 at 08:36:31AM -0700, Andy Lutomirski wrote:
> What if we make 32-bit PTI depend on PAE?
It already does, PTI support for legacy paging had to be removed because
there were memory corruption problems with THP. The reason was that huge
PTEs in the user-space area were mapped in
On Sun, May 10, 2020 at 11:34:49AM -0700, Linus Torvalds wrote:
> On Sun, May 10, 2020 at 5:26 AM Joerg Roedel wrote:
> >
> >The first race condition was around
> > the non-atomic update of the domain page-table root pointer
> > and the v
pressure within a few days of testing. He confirmed
that he has seen no issues anymore with the fixes included
here.
- Fix for a list-handling bug in the VirtIO IOMMU driver.
Joerg Roedel (5):
iommu
On Sat, May 09, 2020 at 10:05:43PM -0700, Andy Lutomirski wrote:
> On Sat, May 9, 2020 at 2:57 PM Joerg Roedel wrote:
> I spent some time looking at the code, and I'm guessing you're talking
> about the 3-level !SHARED_KERNEL_PMD case. I can't quite figure out
> what's going on.
Hi Andy,
On Sat, May 09, 2020 at 12:05:29PM -0700, Andy Lutomirski wrote:
> 1. Non-PAE. There is a single 4k top-level page table per mm, and
> this table contains either 512 or 1024 entries total. Of those
> entries, some fraction (half or less) control the kernel address
> space, and some
On Sat, May 09, 2020 at 11:25:16AM +0200, Peter Zijlstra wrote:
> Right; it's just that the moment you do trigger it, it'll iterate that
> pgd_list and that is potentially huge. Then again, that's not a new
> problem.
>
> I suppose we can deal with it if/when it becomes an actual problem.
>
> I
On Fri, May 08, 2020 at 04:49:17PM -0700, Andy Lutomirski wrote:
> On Fri, May 8, 2020 at 2:36 PM Joerg Roedel wrote:
> >
> > On Fri, May 08, 2020 at 02:33:19PM -0700, Andy Lutomirski wrote:
> > > On Fri, May 8, 2020 at 7:40 AM Joerg Roedel wrote:
> >
> >
On Fri, May 08, 2020 at 02:33:19PM -0700, Andy Lutomirski wrote:
> On Fri, May 8, 2020 at 7:40 AM Joerg Roedel wrote:
> What's the maximum on other system types? It might make more sense to
> take the memory hit and pre-populate all the tables at boot so we
> never have to sync
Hi Peter,
thanks for reviewing this!
On Fri, May 08, 2020 at 09:20:00PM +0200, Peter Zijlstra wrote:
> The only concern I have is the pgd_lock lock hold times.
>
> By not doing on-demand faults anymore, and consistently calling
> sync_global_*(), we iterate that pgd_list thing much more often
On Fri, May 08, 2020 at 02:58:22PM -0400, Steven Rostedt wrote:
> You'll need to fold this into this patch, as my patch has already hit
> Linus's tree.
Yeah, have it on my todo-list already when I rebase this.
> But I applied your whole series and I'm not able to reproduce the bug.
>
>
On Fri, May 08, 2020 at 09:10:48PM +0200, Peter Zijlstra wrote:
> On Fri, May 08, 2020 at 04:40:38PM +0200, Joerg Roedel wrote:
> > + if (mask & ARCH_PAGE_TABLE_SYNC_MASK)
> > + arch_sync_kernel_mappings(start, end);
>
> So you're relying on the
On Tue, May 05, 2020 at 08:47:47PM +0200, Julia Lawall wrote:
> Elsewhere in the file, there is a list_for_each_entry with
> >resv_regions as the second argument, suggesting that
> >resv_regions is the list head. So exchange the
> arguments on the list_add call to put the list head in the
>
+ Baolu, Maintainer of Intel IOMMU
Baolu, does that ring any bells?
On Wed, May 06, 2020 at 04:46:02PM +0200, Uwe Kleine-König wrote:
> Hello,
>
> On my Lenovo T460p I cannot shutdown and reboot when the iommu is
> enabled. This is using linux 5.2.7 as provided by Debian, 5.6.4 has the
> same
On Wed, May 06, 2020 at 11:17:04AM -0400, Steven Rostedt wrote:
> OK, I did take authorship. At least it will be me who gets the blame ;-)
Okay, I meanwhile worked on the removal of vmalloc_sync_(un)mappings.
Let's see what people think about it.
Regards,
Joerg
From: Joerg Roedel
Implement the function to sync changes in vmalloc and ioremap ranges
to all page-tables.
Signed-off-by: Joerg Roedel
---
arch/x86/include/asm/pgtable-2level_types.h | 2 ++
arch/x86/include/asm/pgtable-3level_types.h | 2 ++
arch/x86/mm/fault.c
From: Joerg Roedel
Track at which levels in the page-table entries were modified by
vmap/vunmap. After the page-table has been modified, use that
information do decide whether the new arch_sync_kernel_mappings()
needs to be called.
Signed-off-by: Joerg Roedel
---
include/linux/vmalloc.h | 11
From: Joerg Roedel
These functions are not needed anymore because the vmalloc and ioremap
mappings are now synchronized when they are created or teared down.
Remove all callers and function definitions.
Signed-off-by: Joerg Roedel
---
arch/x86/mm/fault.c | 37
From: Joerg Roedel
Add page-table allocation functions which will keep track of changed
directory entries. They are needed for new PGD, P4D, PUD, and PMD
entries and will be used in vmalloc and ioremap code to decide whether
any changes in the kernel mappings need to be synchronized between
page
From: Joerg Roedel
Track at which levels in the page-table entries were modified by
ioremap_page_range(). After the page-table has been modified, use that
information do decide whether the new arch_sync_kernel_mappings()
needs to be called. The iounmap path re-uses vunmap(), which has
already
/
Joerg Roedel (7):
mm: Add functions to track page directory modifications
mm/vmalloc: Track which page-table levels were modified
mm/ioremap: Track which page-table levels were modified
x86/mm/64: Implement arch_sync_kernel_mappings()
x86/mm/32: Implement arch_sync_kernel_mappings()
mm
From: Joerg Roedel
Implement the function to sync changes in vmalloc and ioremap ranges
to all page-tables.
Signed-off-by: Joerg Roedel
---
arch/x86/include/asm/pgtable_64_types.h | 2 ++
arch/x86/mm/init_64.c | 5 +
2 files changed, 7 insertions(+)
diff --git a/arch
From: Joerg Roedel
Remove fault handling on vmalloc areas, as the vmalloc code now takes
care of synchronizing changes to all page-tables in the system.
Signed-off-by: Joerg Roedel
---
arch/x86/include/asm/switch_to.h | 23 --
arch/x86/kernel/setup_percpu.c | 6 +-
arch/x86/mm
On Mon, May 04, 2020 at 02:54:08PM +0200, Joerg Roedel wrote:
> Joerg Roedel (5):
> iommu/amd: Fix race in increase_address_space()/fetch_pte()
> iommu/amd: Do not loop forever when trying to increase address space
> iommu/amd: Call domain_flush_complete() in update_domain()
&
On Wed, Apr 29, 2020 at 03:36:38PM +0200, Joerg Roedel wrote:
> Please review. If there are no objections I plan to put these patches
> into the IOMMU tree early next week.
Series is now applied.
ds,
Joerg
>From a265290761dc9d87d35892dc821fd0f5c99f8b34 Mon Sep 17 00:00:00 2001
From: Joerg Roedel
Date: Tue, 5 May 2020 14:17:57 +0200
Subject: [PATCH] tracing: Call vmalloc_sync_mappings() after alloc_percpu()
Tracing code allocates percpu memory which is touched when trace events
ha
On Mon, May 04, 2020 at 01:40:42PM -0400, Steven Rostedt wrote:
> Seems that your patch caused a lockdep splat on my box:
>
>
> WARNING: possible irq lock inversion dependency detected
> 5.7.0-rc3-test+ #249 Not tainted
>
The following commit has been merged into the x86/boot branch of tip:
Commit-ID: 34bb49229f19399a5b45c323afb5749f31f7876c
Gitweb:
https://git.kernel.org/tip/34bb49229f19399a5b45c323afb5749f31f7876c
Author:Joerg Roedel
AuthorDate:Tue, 28 Apr 2020 17:16:22 +02:00
Committer
On Mon, May 04, 2020 at 11:38:43AM -0400, Mathieu Desnoyers wrote:
> - On May 4, 2020, at 11:31 AM, Joerg Roedel jroe...@suse.de wrote:
> > Tried this before, actually I put it into the caller of
> > pcpu_mem_zalloc(), but that didn't fix the problem for me. Stevens
> >
On Mon, May 04, 2020 at 11:28:46AM -0400, Mathieu Desnoyers wrote:
> - On May 4, 2020, at 11:12 AM, Joerg Roedel jroe...@suse.de wrote:
> Placing this here is inefficient. It syncs mappings for each percpu
> allocation.
> I would recommend moving it right after __vmalloc
fb2ed Mon Sep 17 00:00:00 2001
From: Joerg Roedel
Date: Mon, 4 May 2020 17:11:41 +0200
Subject: [PATCH] percpu: Sync vmalloc mappings in pcpu_alloc() and
free_percpu()
Sync the vmalloc mappings for all page-tables in the system when
allocating and freeing per-cpu memory. This is necessary for
arch
From: Joerg Roedel
The update_domain() function is expected to also inform the hardware
about domain changes. This needs a COMPLETION_WAIT command to be sent
to all IOMMUs which use the domain.
Tested-by: Qian Cai
Signed-off-by: Joerg Roedel
---
drivers/iommu/amd_iommu.c | 1 +
1 file
901 - 1000 of 6605 matches
Mail list logo
