From: Vasant Hegde <vasant.hegde@amd.com>
To: Matt Fleming <matt@readmodwrite.com>, Joerg Roedel <joro@8bytes.org>
Cc: Suravee Suthikulpanit <suravee.suthikulpanit@amd.com>,
Ashish Kalra <ashish.kalra@amd.com>,
Sairaj Kodilkar <sarunkod@amd.com>,
Ankit Soni <Ankit.Soni@amd.com>, Baoquan He <bhe@redhat.com>,
iommu@lists.linux.dev, linux-kernel@vger.kernel.org,
stable@vger.kernel.org, kernel-team@cloudflare.com,
Matt Fleming <mfleming@cloudflare.com>
Subject: Re: [PATCH v2 2/2] iommu/amd: Don't allocate kdump device table from DMA32
Date: Wed, 14 Oct 2026 10:23:30 +0530 [thread overview]
Message-ID: <84a84584-404d-4e76-a2fd-65bb4aafab47@amd.com> (raw)
In-Reply-To: <20261013121944.4060097-3-matt@readmodwrite.com>
On 10/13/2026 5:49 PM, Matt Fleming wrote:
> From: Matt Fleming <mfleming@cloudflare.com>
>
> Booting a kdump kernel with crashkernel=X,high crashkernel=0,low on an
> AMD system fails the per-segment device table allocation because there
> is no memory below 4G:
>
> swapper/0: page allocation failure: order:9, mode:0x40104(GFP_DMA32|__GFP_ZERO|__GFP_COMP)
> iommu_alloc_pages_node_sz+0x7f/0x150
> alloc_pci_segment+0x4bd/0x650
> iommu_go_to_state+0x213d/0x34e0
> amd_iommu_prepare+0x39/0xa0
> irq_remapping_prepare+0x83/0xd0
> enable_IR_x2apic+0x61/0x370
>
> On our E810 systems, the kdump kernel booted but ice MSI-X interrupts
> never fired and the TX queues timed out.
>
> Commit b336781b82cc ("iommu/amd: Allocate memory below 4G for dev table
> if translation pre-enabled") allocated device tables below 4G. At the
> time, the kdump kernel programmed a copy of the old table into the base
> register with the IOMMU still enabled. The 64-bit register is updated
> as two 32-bit halves, so the running IOMMU could see a half-written,
> invalid table pointer. Keeping both tables below 4G leaves the upper
> half zero throughout the update, so the pointer stays valid.
>
> Since commit 38e5f33ee359 ("iommu/amd: Reuse device table for kdump")
> the kdump kernel reuses the previous kernel's table without writing the
> base register, so its newly allocated table is discarded when reuse
> succeeds. If reuse fails, the previous patch programs the new table only
> after disabling the IOMMU. Either way, the kdump kernel's table doesn't
> need to be below 4G.
>
> The previous kernel still allocates its table from DMA32, so the kdump
> kernel's check that the old table is below 4G still works. Drop
> GFP_DMA32 for kdump kernels only.
This one is OK as its regression fix. But with all the changes went in I am
wondering why we need GFP_DMA32 flag for allocation. There are only two cases
where transactions may be enabled:
- During boot (BIOS enabled DMA) : kernel will disable IOMMU before
configuring device table base address w/ new value
- During kdump : We are reusing previous kernels device table. If it fails
then kernel will disable IOMMU and re-configures it with new vlaue.
Anyway, we will look into it in detail and run more experiments. For now this
fix is fine. With that,
Reviewed-by: Vasant Hegde <vasant.hegde@amd.com>
-Vasant
next prev parent reply other threads:[~2026-10-14 4:53 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-13 12:19 [PATCH v2 0/2] iommu/amd: Fix device table setup in kdump kernels Matt Fleming
2026-10-13 12:19 ` [PATCH v2 1/2] iommu/amd: Program device table when kdump reuse fails Matt Fleming
2026-10-13 12:19 ` [PATCH v2 2/2] iommu/amd: Don't allocate kdump device table from DMA32 Matt Fleming
2026-10-14 4:53 ` Vasant Hegde [this message]
2026-10-14 13:47 ` [PATCH v2 0/2] iommu/amd: Fix device table setup in kdump kernels Joerg Roedel
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=84a84584-404d-4e76-a2fd-65bb4aafab47@amd.com \
--to=vasant.hegde@amd.com \
--cc=Ankit.Soni@amd.com \
--cc=ashish.kalra@amd.com \
--cc=bhe@redhat.com \
--cc=iommu@lists.linux.dev \
--cc=joro@8bytes.org \
--cc=kernel-team@cloudflare.com \
--cc=linux-kernel@vger.kernel.org \
--cc=matt@readmodwrite.com \
--cc=mfleming@cloudflare.com \
--cc=sarunkod@amd.com \
--cc=stable@vger.kernel.org \
--cc=suravee.suthikulpanit@amd.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.