aged pages, then create atomic_pool_dma
if yes. Otherwise just skip it.
Fixes: 6f599d84231f ("x86/kdump: Always reserve the low 1M when the crashkernel
option is specified")
Cc: sta...@vger.kernel.org
Signed-off-by: Baoquan He
Cc: Christoph Hellwig
Cc: Marek Szyprowski
Cc: Rob
MA: failed to allocate 128 KiB GFP_KERNEL|GFP_DMA pool for atomic allocation
DMA: preallocated 128 KiB GFP_KERNEL|GFP_DMA32 pool for atomic allocations
Here, let's check if DMA zone has managed pages, then create atomic_pool_dma
if yes. Otherwise just skip it.
Signed-off-by: Baoquan He
Cc: Christo
On 08/10/21 at 03:52pm, Tom Lendacky wrote:
> On 8/5/21 1:54 AM, Baoquan He wrote:
> > On 06/24/21 at 11:47am, Robin Murphy wrote:
> >> On 2021-06-24 10:29, Baoquan He wrote:
> >>> On 06/24/21 at 08:40am, Christoph Hellwig wrote:
> >>>> So reduce
aged pages, then create atomic_pool_dma
if yes. Otherwise just skip it.
Signed-off-by: Baoquan He
Cc: Christoph Hellwig
Cc: Marek Szyprowski
Cc: Robin Murphy
Cc: iommu@lists.linux-foundation.org
---
kernel/dma/pool.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/
On 06/24/21 at 11:47am, Robin Murphy wrote:
> On 2021-06-24 10:29, Baoquan He wrote:
> > On 06/24/21 at 08:40am, Christoph Hellwig wrote:
> > > So reduce the amount allocated. But the pool is needed for proper
> > > operation on systems with memory encryption
On 06/24/21 at 08:40am, Christoph Hellwig wrote:
> So reduce the amount allocated. But the pool is needed for proper
> operation on systems with memory encryption. And please add the right
> maintainer or at least mailing list for the code you're touching next
> time.
Oh, I thoutht it's memory
Forgot CC-ing Jerry, add him.
On 09/23/20 at 10:26am, Baoquan He wrote:
> A regression failure of kdump kernel boot was reported on a HPE system.
> Bisect points at commit 387caf0b759ac43 ("iommu/amd: Treat per-device
> exclusion ranges as r/w unity-mapped regions") as
regions.
https://lists.linuxfoundation.org/pipermail/iommu/2019-November/040117.html
Signed-off-by: Baoquan He
---
drivers/iommu/amd/init.c | 21 +
1 file changed, 13 insertions(+), 8 deletions(-)
diff --git a/drivers/iommu/amd/init.c b/drivers/iommu/amd/init.c
index
lock.memblock_type.regions +
> memblock.memblock_type.cnt);\
> +/**
> + * for_each_mem_region - itereate over registered memory regions
~~~~~
Wonder why emphasize 'registered' memory.
Other than this confusion to me, this patch
2 +-
> arch/arm64/kernel/setup.c| 2 +-
> drivers/irqchip/irq-gic-v3-its.c | 2 +-
> include/linux/memblock.h | 12 +++--
> mm/memblock.c| 46 +++-
> 5 files changed, 17 insertions(+), 47 deletions(-)
Reviewed-by: Baoqua
_pfn_range(i, MAX_NUMNODES, _pfn, _pfn, NULL) {
> - start_pfn = min_t(unsigned long, start_pfn, limit_pfn);
> - end_pfn = min_t(unsigned long, end_pfn, limit_pfn);
> - pages += end_pfn - start_pfn;
> - }
> -
> - return PFN_PHYS(pages);
&g
insertions(+), 26 deletions(-)
Applied this patch on top of 5.8, crashkernel reservation works well.
And the code change looks good.
Reviewed-by: Baoquan He
>
> diff --git a/arch/x86/kernel/setup.c b/arch/x86/kernel/setup.c
> index d8de4053c5e8..d7ced6982524 100644
> --- a/arch
isk_size)
> @@ -312,12 +308,6 @@ static void __init reserve_initrd(void)
>
> initrd_start = 0;
>
> - mapped_size = memblock_mem_size(max_pfn_mapped);
> - if (ramdisk_size >= (mapped_size>>1))
> - panic("initrd too large to hand
| 7 ++-
> arch/s390/mm/page-states.c | 6 ++
> arch/sh/mm/init.c| 9 +++--
> mm/memblock.c| 6 ++
> mm/sparse.c | 10 --
> 9 files changed, 35 insertions(+), 51 deletions(-)
>
Reviewed-by: Baoquan He
_region_memory_end_pfn(reg) -
> -memblock_region_memory_base_pfn(reg);
> + unsigned long total_pages = PHYS_PFN(memblock_phys_mem_size());
Reviewed-by: Baoquan He
>
> return (total_pages * CONFIG_CMA_SIZE_PERCENTAGE / 100) << PAGE_SHI
| 1 +
> arch/arm64/kernel/machine_kexec_file.c | 6 ++
> arch/s390/kernel/crash_dump.c | 8
> include/linux/memblock.h | 18 ++
> mm/page_alloc.c| 3 +--
> 5 files changed, 22 insertions(+), 14 deletions(-)
Revi
ernel.
>
> Signed-off-by: Mike Rapoport
> ---
> arch/s390/kernel/setup.c | 4 ++--
> include/linux/memblock.h | 12 +---
> mm/memblock.c| 13 +++--
> 3 files changed, 14 insertions(+), 15 deletions(-)
Nice clean up.
Reviewed-by: Baoquan He
>
memblock = {
> .current_limit = MEMBLOCK_ALLOC_ANYWHERE,
> };
>
> +#define for_each_memblock_type(i, memblock_type, rgn)
> \
> + for (i = 0, rgn = _type->regions[0]; \
> +
On 07/28/20 at 05:15pm, Mike Rapoport wrote:
> On Tue, Jul 28, 2020 at 07:02:54PM +0800, Baoquan He wrote:
> > On 07/28/20 at 08:11am, Mike Rapoport wrote:
> > > From: Mike Rapoport
> > >
> > > numa_clear_kernel_node_hotplug() function first traverses numa_
On 07/28/20 at 08:11am, Mike Rapoport wrote:
> From: Mike Rapoport
>
> numa_clear_kernel_node_hotplug() function first traverses numa_meminfo
> regions to set node ID in memblock.reserved and than traverses
> memblock.reserved to update reserved_nodemask to include node IDs that were
> set in
On 03/30/20 at 10:42pm, Alexander Graf wrote:
>
>
> On 30.03.20 15:40, Konrad Rzeszutek Wilk wrote:
> >
> >
> >
> > On Mon, Mar 30, 2020 at 02:06:01PM +0800, Kairui Song wrote:
> > > On Sat, Mar 28, 2020 at 7:57 PM Dave Young wrote:
> > > >
> > > > On 03/26/20 at 05:29pm, Alexander Graf
Hi Lianbo,
On 09/07/18 at 04:18pm, Lianbo Jiang wrote:
> When SME is enabled on AMD machine, the memory is encrypted in the first
> kernel. In this case, SME also needs to be enabled in kdump kernel, and
> we have to remap the old memory with the memory encryption mask.
This patch series looks
On 06/21/18 at 08:12am, Tom Lendacky wrote:
> On 6/21/2018 3:39 AM, Baoquan He wrote:
> > On 06/21/18 at 01:42pm, lijiang wrote:
> >> 在 2018年06月21日 00:42, Tom Lendacky 写道:
> >>> On 6/16/2018 3:27 AM, Lianbo Jiang wrote:
> >>>> In kdump mode, it wil
On 06/21/18 at 09:27pm, lijiang wrote:
> 在 2018年06月21日 18:23, Baoquan He 写道:
> > On 06/21/18 at 01:06pm, lijiang wrote:
> >> 在 2018年06月21日 09:53, Baoquan He 写道:
> >>> On 06/16/18 at 04:27pm, Lianbo Jiang wrote:
> >>>> When SME is enabled in the first ke
On 06/21/18 at 01:06pm, lijiang wrote:
> 在 2018年06月21日 09:53, Baoquan He 写道:
> > On 06/16/18 at 04:27pm, Lianbo Jiang wrote:
> >> When SME is enabled in the first kernel, we will allocate pages
> >> for kdump without encryption in order to be able to boot the
> >&
On 06/21/18 at 01:42pm, lijiang wrote:
> 在 2018年06月21日 00:42, Tom Lendacky 写道:
> > On 6/16/2018 3:27 AM, Lianbo Jiang wrote:
> >> In kdump mode, it will copy the device table of IOMMU from the old
> >> device table, which is encrypted when SME is enabled in the first
> >> kernel. So we must remap
On 06/21/18 at 11:18am, lijiang wrote:
> 在 2018年06月21日 09:21, Baoquan He 写道:
> > On 06/16/18 at 04:27pm, Lianbo Jiang wrote:
> >> It is convenient to remap the old memory encrypted to the second kernel by
> >> calling ioremap_encrypted().
> >>
> >>
On 06/16/18 at 04:27pm, Lianbo Jiang wrote:
> In kdump mode, we need to dump the old memory into vmcore file,
> if SME is enabled in the first kernel, we must remap the old
> memory in encrypted manner, which will be automatically decrypted
> when we read from DRAM. It helps to parse the vmcore
On 06/16/18 at 04:27pm, Lianbo Jiang wrote:
> When SME is enabled in the first kernel, we will allocate pages
> for kdump without encryption in order to be able to boot the
> second kernel in the same manner as kexec, which helps to keep
> the same code style.
>
> Signed-off-by: Lianbo Jiang
>
On 06/16/18 at 04:27pm, Lianbo Jiang wrote:
> It is convenient to remap the old memory encrypted to the second kernel by
> calling ioremap_encrypted().
>
> When sme enabled on AMD server, we also need to support kdump. Because
> the memory is encrypted in the first kernel, we will remap the old
On 03/01/18 at 01:05pm, Bjorn Helgaas wrote:
> [+cc Joerg, David, iommu list]
>
> On Thu, Mar 01, 2018 at 12:44:26PM -0500, Sinan Kaya wrote:
> > Hi,
> >
> > We are seeing IOMMU faults when booting the kdump kernel on ARM64.
> >
> > [7.220162] arm-smmu-v3 arm-smmu-v3.0.auto: event 0x02
Hi Joerg,
On 02/13/18 at 02:25pm, Joerg Roedel wrote:
> Hi Baoquan,
>
> On Fri, Jan 26, 2018 at 04:06:22PM +0800, Baoquan He wrote:
> > Saw Huawei's bug report about kdump kernel hang when intel_iommu=off
> > is set. I met the similar problem in amd system, only set amd_i
On 01/23/18 at 06:20pm, Weilong Chen wrote:
> Hi,
>
> We came across this problem:
> Second kernel hang with intel_iommu=on
>
> We can reproduce the problem by the following steps:
> 1. start the kernel with intel_iommu=on
> 2. ifconfig eth6 up;ifconfig eth8 up.(eth6 is Intel Corporation 82599ES
(-EBUSY) directly.
Reported-by: Dan Carpenter <dan.carpen...@oracle.com>
Fixes: df3f7a6e8e85 ('iommu/amd: Use is_attach_deferred call-back')
Signed-off-by: Baoquan He <b...@redhat.com>
---
drivers/iommu/amd_iommu.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/iommu/a
On 08/24/17 at 03:53pm, Dan Carpenter wrote:
> On Thu, Aug 24, 2017 at 08:47:33PM +0800, Baoquan He wrote:
> > On 08/24/17 at 03:32pm, Dan Carpenter wrote:
> > > Take a look at this code for example. But all the places which call
> > > get_domain() are the same:
On 08/24/17 at 03:32pm, Dan Carpenter wrote:
> Take a look at this code for example. But all the places which call
> get_domain() are the same:
>
> drivers/iommu/amd_iommu.c
> 2648 page = virt_to_page(virt_addr);
> 2649 size = PAGE_ALIGN(size);
> 2650
> 2651
On 08/24/17 at 03:11pm, Dan Carpenter wrote:
> On Thu, Aug 24, 2017 at 07:56:47PM +0800, Baoquan He wrote:
> > In get_domain(), 'domain' could still be NULL before it's passed to
> > dma_ops_domain() to dereference. For safety, check if 'domain' is
> > NULL before pass
In get_domain(), 'domain' could still be NULL before it's passed to
dma_ops_domain() to dereference. For safety, check if 'domain' is
NULL before passing to dma_ops_domain().
Reported-by: Dan Carpenter <dan.carpen...@oracle.com>
Signed-off-by: Baoquan He <b...@redhat.com>
---
d
Hi Dan,
On 08/24/17 at 02:04pm, Dan Carpenter wrote:
> Hello Baoquan He,
>
> This is a semi-automatic email about new static checker warnings.
>
> The patch df3f7a6e8e85: "iommu/amd: Use is_attach_deferred call-back"
> from Aug 9, 2017, leads to the following Sm
On 08/15/17 at 06:18pm, Joerg Roedel wrote:
> On Wed, Aug 09, 2017 at 04:33:32PM +0800, Baoquan He wrote:
> > Baoquan He (12):
> > iommu/amd: Detect pre enabled translation
> > iommu/amd: add several helper functions
> > Revert "iommu/amd: Suppress IO_PAGE_FAU
It's ok to disable iommu early in normal kernel or in kdump kernel when
amd_iommu=off is specified. While we should not disable it in kdump kernel
when on-flight dma is still on-going.
Signed-off-by: Baoquan He <b...@redhat.com>
---
v9->v10:
Change to call disable_iommus() in norm
are recoverable for the device and we should not allow the
device to change old-kernels data when we don't have to.
Signed-off-by: Baoquan He <b...@redhat.com>
---
v9->v10:
Clear the DTE_FLAG_GV when handle the GCR3 table root pointer.
drivers/iommu/amd_iommu.c
Implement call-back is_attach_deferred and use it to defer the
domain attach from iommu driver init to device driver init when
iommu is pre-enabled in kdump kernel.
Signed-off-by: Baoquan He <b...@redhat.com>
---
drivers/iommu/amd_iommu.c | 23 ++-
1 file chang
accidentally in corrupted
1st kernel.
Signed-off-by: Baoquan He <b...@redhat.com>
---
v9->v10:
The judgement of the address of old_devtb_phys should be '>= 0x1ULL'.
drivers/iommu/amd_iommu_init.c | 9 +++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/d
This new call-back will be used to check if the domain attach need be
deferred for now. If yes, the domain attach/detach will return directly.
Signed-off-by: Baoquan He <b...@redhat.com>
---
drivers/iommu/iommu.c | 8
include/linux/iommu.h | 1 +
2 files changed, 9 insertions(+)
Add functions to check whether translation is already enabled in IOMMU.
Signed-off-by: Baoquan He <b...@redhat.com>
---
drivers/iommu/amd_iommu_init.c | 24
drivers/iommu/amd_iommu_proto.h | 1 +
drivers/iommu/amd_iommu_types.h | 3 +++
3 files changed, 28 inse
Firstly split the dev table entry copy into address translation part
and irq remapping part. Because these two parts could be enabled
independently.
Secondly do sanity check for address translation and irq remap of old
dev table entry separately.
Signed-off-by: Baoquan He <b...@redhat.
Move single iommu enabling codes into a wrapper function early_enable_iommu().
This can make later kdump change easier.
And also add iommu_disable_command_buffer and iommu_disable_event_buffer
for later usage.
Signed-off-by: Baoquan He <b...@redhat.com>
---
drivers/iommu/amd_iommu_init.
and enable guest vapic.
- Flush all caches
Signed-off-by: Baoquan He <b...@redhat.com>
---
v9->v10:
Add global variable amd_iommu_pre_enabled to mark if all IOMMUs are
pre-enabled. If any one is not pre-enabled, just set it as false.
Check amd_iommu_pre_enabled in copy_device_table(
patch to reset
it during driver init. IO_PAGE_FAULT can't be seen anymore.
Below is link of v5 post.
https://lists.linuxfoundation.org/pipermail/iommu/2016-September/018527.html
Baoquan He (12):
iommu/amd: Detect pre enabled translation
iommu/amd: add several helper functions
Re
the old
io-page tables. Then on-flight DMA can continue looking it up.
And also define MACRO DEV_DOMID_MASK to replace magic number 0xULL, it can
be
reused in copy_dev_tables().
Signed-off-by: Baoquan He <b...@redhat.com>
---
v9->v10:
Move the copy code block out of the i
This reverts commit 54bd63570484167cb13edf81e31fff107b879981.
We still need the IO_PAGE_FAULT message to warn error after the
issue of on-flight dma in kdump kernel is fixed.
Signed-off-by: Baoquan He <b...@redhat.com>
---
drivers/iommu/amd_iommu.c | 3 +--
drivers/iommu/amd_iommu_
In AMD-Vi spec several bits of IO PTE fields and DTE fields are similar
so that both of them can share the same MACRO definition. However
defining them respectively can make code more read-able. Do it now.
Signed-off-by: Baoquan He <b...@redhat.com>
---
drivers/iommu/amd_iommu.c
On 08/04/17 at 02:30pm, Joerg Roedel wrote:
> On Tue, Aug 01, 2017 at 07:37:28PM +0800, Baoquan He wrote:
> > @@ -2466,11 +2472,21 @@ static struct protection_domain *get_domain(struct
> > device *dev)
> > return ERR_PTR(-EINVAL);
> >
> > d
On 08/04/17 at 02:21pm, Joerg Roedel wrote:
> On Tue, Aug 01, 2017 at 07:37:22PM +0800, Baoquan He wrote:
> > static void init_device_table_dma(void)
> > {
> > @@ -2137,9 +2140,49 @@ static void early_enable_iommu(struct amd_iommu
> > *iommu)
> > sta
On 08/04/17 at 02:25pm, Joerg Roedel wrote:
> On Tue, Aug 01, 2017 at 07:37:26PM +0800, Baoquan He wrote:
> > AMD pointed out it's unsafe to update the device-table while iommu
> > is enabled. It turns out that device-table pointer update is split
> > up into two 32bit writes
On 08/04/17 at 02:51pm, Joerg Roedel wrote:
> On Fri, Aug 04, 2017 at 08:30:39PM +0800, Baoquan He wrote:
> > Sorry, I don't get 'this one' meaning, are you suggesting the copy for
> > loop should be take out of the iommu for loop?
> >
> > About the temporary copy o
On 08/04/17 at 02:09pm, Joerg Roedel wrote:
>
> On Tue, Aug 01, 2017 at 07:37:21PM +0800, Baoquan He wrote:
> > + for_each_iommu(iommu) {
..
> > + if (copied)
> > + continue;
> > +
> > +
Hi Joerg,
Thanks for your reviewing!
On 08/04/17 at 02:09pm, Joerg Roedel wrote:
> Hi Baoquan,
>
> On Tue, Aug 01, 2017 at 07:37:21PM +0800, Baoquan He wrote:
> > + for_each_iommu(iommu) {
> > + /* All IOMMUs should use the same device table wi
are recoverable for the device and we should not allow the
device to change old-kernels data when we don't have to.
Signed-off-by: Baoquan He <b...@redhat.com>
---
drivers/iommu/amd_iommu.c | 28 +++-
drivers/iommu/amd_iommu_init.c | 11 +++
drivers
It's ok to disable iommu in normal kernel. While there's no need
to disable it in kdump kernel after the on-flight dma issue has
heen fixed.
Signed-off-by: Baoquan He <b...@redhat.com>
---
drivers/iommu/amd_iommu_init.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff
When handle deferred domain attach, we need check if the domain is
v2. If not, should try to clear out the GV flag which could be
copied from the old device table entry.
Signed-off-by: Baoquan He <b...@redhat.com>
---
drivers/iommu/amd_iommu.c | 18 +-
1 file chang
This reverts commit 54bd63570484167cb13edf81e31fff107b879981.
We still need the IO_PAGE_FAULT message to warn error after the
issue of on-flight dma in kdump kernel is fixed.
Signed-off-by: Baoquan He <b...@redhat.com>
---
drivers/iommu/amd_iommu.c | 3 +--
drivers/iommu/amd_iommu_
accidentally in corrupted
1st kernel.
Signed-off-by: Baoquan He <b...@redhat.com>
---
drivers/iommu/amd_iommu_init.c | 9 +++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/drivers/iommu/amd_iommu_init.c b/drivers/iommu/amd_iommu_init.c
index 6a77b99d08e4..8c6431ac5698
This new call-back will be used to check if the domain attach need be
deferred for now. If yes, the domain attach/detach will return directly.
Signed-off-by: Baoquan He <b...@redhat.com>
---
drivers/iommu/iommu.c | 8
include/linux/iommu.h | 1 +
2 files changed, 9 insertions(+)
the old
io-page tables. Then on-flight DMA can continue looking it up.
And also define MACRO DEV_DOMID_MASK to replace magic number 0xULL, it can
be
reused in copy_dev_tables().
Signed-off-by: Baoquan He <b...@redhat.com>
---
drivers/iommu/amd_iommu.c | 2 +-
drivers
Implement call-back is_attach_deferred and use it to defer the
domain attach from iommu driver init to device driver init when
iommu is pre-enabled in kdump kernel.
Signed-off-by: Baoquan He <b...@redhat.com>
---
drivers/iommu/amd_iommu.c | 23 ++-
1 file chang
and enable guest vapic.
- Flush all caches
Signed-off-by: Baoquan He <b...@redhat.com>
---
drivers/iommu/amd_iommu_init.c | 57 --
1 file changed, 50 insertions(+), 7 deletions(-)
diff --git a/drivers/iommu/amd_iommu_init.c b/drivers/iommu/amd_iommu_
Firstly split the dev table entry copy into address translation part
and irq remapping part. Because these two parts could be enabled
independently.
Secondly do sanity check for address translation and irq remap of old
dev table entry separately.
Signed-off-by: Baoquan He <b...@redhat.
an't be seen anymore.
Below is link of v5 post.
https://lists.linuxfoundation.org/pipermail/iommu/2016-September/018527.html
Baoquan He (13):
iommu/amd: Detect pre enabled translation
iommu/amd: add several helper functions
Revert "iommu/amd: Suppress IO_PAGE_FAULTs in kdump ke
Add functions to check whether translation is already enabled in IOMMU.
Signed-off-by: Baoquan He <b...@redhat.com>
---
drivers/iommu/amd_iommu_init.c | 24
drivers/iommu/amd_iommu_proto.h | 1 +
drivers/iommu/amd_iommu_types.h | 3 +++
3 files changed, 28 inse
In AMD-Vi spec several bits of IO PTE fields and DTE fields are similar
so that both of them can share the same MACRO definition. However
defining them respectively can make code more read-able. Do it now.
Signed-off-by: Baoquan He <b...@redhat.com>
---
drivers/iommu/amd_iommu.c
Move single iommu enabling codes into a wrapper function early_enable_iommu().
This can make later kdump change easier.
And also add iommu_disable_command_buffer and iommu_disable_event_buffer
for later usage.
Signed-off-by: Baoquan He <b...@redhat.com>
---
drivers/iommu/amd_iommu_init.
On 07/31/17 at 12:21pm, Joerg Roedel wrote:
> Hi Baoquan,
>
> On Mon, Jul 31, 2017 at 06:15:30PM +0800, Baoquan He wrote:
> > I plan to add GFP_DMA32 when allocate amd_iommu_dev_table in
> > early_amd_iommu_init() as below. Then in kdump kernel we don't need to
Hi Joerg,
On 07/28/17 at 05:06pm, Baoquan He wrote:
> Hi Joerg,
>
> On 07/27/17 at 05:55pm, Joerg Roedel wrote:
> > On Fri, Jul 21, 2017 at 04:59:08PM +0800, Baoquan He wrote:
> > > AMD pointed out it's unsafe to update the device-table while iommu
> > > is
Hi Joerg,
On 07/27/17 at 05:06pm, Joerg Roedel wrote:
> On Fri, Jul 21, 2017 at 04:59:00PM +0800, Baoquan He wrote:
> > Move single iommu enabling codes into a wrapper function
> > early_enable_iommu().
> > This can make later kdump change easier.
On 07/28/17 at 01:18pm, Joerg Roedel wrote:
> On Fri, Jul 28, 2017 at 07:15:53PM +0800, Baoquan He wrote:
> > On 07/28/17 at 01:14pm, Joerg Roedel wrote:
> > > Yes, exactly, the first device table also needs to be allocated with
> > > GFP_DMA32 so that it ends
On 07/28/17 at 01:14pm, Joerg Roedel wrote:
> On Fri, Jul 28, 2017 at 05:06:19PM +0800, Baoquan He wrote:
> > Do you mean the allocation of amd_iommu_dev_table in
> > early_amd_iommu_init() also need be addressed for 1st kernel? Seems we
> > don't make sure that for 1s
On 07/27/17 at 05:58pm, Joerg Roedel wrote:
> On Fri, Jul 21, 2017 at 04:59:11PM +0800, Baoquan He wrote:
> > From: root <r...@amd-dinar-02.lab.bos.redhat.com>
>
> You probaly need to reset the author on this one.
Oops, sorry. I made this patch on a testing machine. Wil
On 07/27/17 at 05:57pm, Joerg Roedel wrote:
> On Fri, Jul 21, 2017 at 04:59:09PM +0800, Baoquan He wrote:
> > When iommu is pre_enabled in kdump kernel, if a device is set up with
> > guest translations (DTE.GV=1), then don't copy GCR3 table root pointer
> > but move the de
Hi Joerg,
On 07/27/17 at 05:55pm, Joerg Roedel wrote:
> On Fri, Jul 21, 2017 at 04:59:08PM +0800, Baoquan He wrote:
> > AMD pointed out it's unsafe to update the device-table while iommu
> > is enabled. It turns out that device-table pointer update is split
> > up
On 07/27/17 at 05:38pm, Joerg Roedel wrote:
> On Fri, Jul 21, 2017 at 04:59:04PM +0800, Baoquan He wrote:
> > @@ -2128,9 +2131,43 @@ static void early_enable_iommu(struct amd_iommu
> > *iommu)
> > static void early_enable_iommus(void)
> > {
> > stru
On 07/27/17 at 05:53pm, Joerg Roedel wrote:
> On Fri, Jul 21, 2017 at 04:59:07PM +0800, Baoquan He wrote:
> > +static bool amd_iommu_is_attach_deferred(struct iommu_domain *domain,
> > +struct device *dev)
> > +{
> > + struct iom
On 07/27/17 at 05:29pm, Joerg Roedel wrote:
> On Fri, Jul 21, 2017 at 04:59:03PM +0800, Baoquan He wrote:
> > Add function copy_dev_tables to copy the old DEV table entries of the
> > panicked
>
> Since there is only one (for now), you can name the function in
>
On 07/27/17 at 05:06pm, Joerg Roedel wrote:
> On Fri, Jul 21, 2017 at 04:59:00PM +0800, Baoquan He wrote:
> > Move single iommu enabling codes into a wrapper function
> > early_enable_iommu().
> > This can make later kdump change easier.
> >
> > And also
On 07/27/17 at 05:04pm, Joerg Roedel wrote:
> On Fri, Jul 21, 2017 at 04:58:59PM +0800, Baoquan He wrote:
> > diff --git a/drivers/iommu/amd_iommu_types.h
> > b/drivers/iommu/amd_iommu_types.h
> > index 294a409e283b..d15966b62b33 100644
> > --- a/drivers/iommu/amd_iomm
the system]
>
> url:
> https://github.com/0day-ci/linux/commits/Baoquan-He/Fix-the-on-flight-DMA-issue-on-system-with-amd-iommu/20170724-060048
> base: https://git.kernel.org/pub/scm/linux/kernel/git/joro/iommu.git next
> config: x86_64-randconfig-x005-201730 (attached as .confi
This new call-back will be used to check if the domain attach need be
deferred for now. If yes, the domain attach/detach will return directly.
Signed-off-by: Baoquan He <b...@redhat.com>
---
drivers/iommu/iommu.c | 8
include/linux/iommu.h | 1 +
2 files changed, 9 insertions(+)
this is to allocate the device-table below
4GB if translation is pre-enabled in kdump kernel. If allocation failed,
still use the old one.
Signed-off-by: Baoquan He <b...@redhat.com>
---
drivers/iommu/amd_iommu_init.c | 12
1 file changed, 12 insertions(+)
diff --git a/drivers
Implement call-back is_attach_deferred and use it to defer the
domain attach from iommu driver init to device driver init when
iommu is pre-enabled in kdump kernel.
Signed-off-by: Baoquan He <b...@redhat.com>
---
drivers/iommu/amd_iommu.c | 23 ++-
1 file chang
When handle deferred domain attach, we need check if the domain is
v2. If not, should try to clear out the GV flag which could be
copied from the old device table entry.
Signed-off-by: Baoquan He <b...@redhat.com>
---
drivers/iommu/amd_iommu.c | 18 +-
1 file chang
From: root <r...@amd-dinar-02.lab.bos.redhat.com>
It's ok to disable iommu in normal kernel. While there's no need
to disable it in kdump kernel after the on-flight dma issue has
heen fixed.
Signed-off-by: Baoquan He <b...@redhat.com>
---
drivers/iommu/amd_iommu_init.c | 3 ++-
1
are recoverable for the device and we should not allow the
device to change old-kernels data when we don't have to.
Signed-off-by: Baoquan He <b...@redhat.com>
---
drivers/iommu/amd_iommu.c | 28 +++-
drivers/iommu/amd_iommu_init.c | 11 +++
drivers
, it can
be
reused in copy_dev_tables().
Signed-off-by: Baoquan He <b...@redhat.com>
---
drivers/iommu/amd_iommu.c | 2 +-
drivers/iommu/amd_iommu_init.c | 55 +
drivers/iommu/amd_iommu_types.h | 1 +
3 files changed, 57 insertions(+), 1 de
, and detect and enable guest vapic.
- Flush all caches
Signed-off-by: Baoquan He <b...@redhat.com>
---
drivers/iommu/amd_iommu_init.c | 51 --
1 file changed, 44 insertions(+), 7 deletions(-)
diff --git a/drivers/iommu/amd_iommu_init.c b/drivers
In AMD-Vi spec several bits of IO PTE fields and DTE fields are similar
so that both of them can share the same MACRO definition. However
defining them respectively can make code more read-able. Do it now.
Signed-off-by: Baoquan He <b...@redhat.com>
---
drivers/iommu/amd_iommu.c
Move single iommu enabling codes into a wrapper function early_enable_iommu().
This can make later kdump change easier.
And also add iommu_disable_command_buffer and iommu_disable_event_buffer
for later usage.
Signed-off-by: Baoquan He <b...@redhat.com>
---
drivers/iommu/amd_iommu_init.
This reverts commit 54bd63570484167cb13edf81e31fff107b879981.
We still need the IO_PAGE_FAULT message to warn error after the
issue of on-flight dma in kdump kernel is fixed.
Signed-off-by: Baoquan He <b...@redhat.com>
---
drivers/iommu/amd_iommu.c | 3 +--
drivers/iommu/amd_iommu_
nymore.
Below is link of v5 post.
https://lists.linuxfoundation.org/pipermail/iommu/2016-September/018527.html
Baoquan He (12):
iommu/amd: Detect pre enabled translation
iommu/amd: add several helper functions
Revert "iommu/amd: Suppress IO_PAGE_FAULTs in kdump kernel"
i
Add functions to check whether translation is already enabled in IOMMU.
Signed-off-by: Baoquan He <b...@redhat.com>
---
drivers/iommu/amd_iommu_init.c | 24
drivers/iommu/amd_iommu_proto.h | 1 +
drivers/iommu/amd_iommu_types.h | 4
3 files changed, 29 inse
1 - 100 of 292 matches
Mail list logo
