linux-kernel - Re: [PATCH v2 1/2] amd/iommu: Preserve domain ids inside the kdump kernel

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <e71c0c1c-8bd8-4ad7-a8ed-c5b005a72788@amd.com>
Date: Tue, 2 Dec 2025 10:51:40 +0530
From: Vasant Hegde <vasant.hegde@....com>
To: Jason Gunthorpe <jgg@...dia.com>
Cc: Sairaj Kodilkar <sarunkod@....com>, iommu@...ts.linux.dev,
 linux-kernel@...r.kernel.org, joro@...tes.org,
 suravee.suthikulpanit@....com, robin.murphy@....com, ashish.kalra@....com,
 will@...nel.org
Subject: Re: [PATCH v2 1/2] amd/iommu: Preserve domain ids inside the kdump
 kernel

Jason,


On 11/26/2025 8:50 PM, Jason Gunthorpe wrote:
> On Wed, Nov 26, 2025 at 01:51:27PM +0530, Vasant Hegde wrote:
>> It looks like on non-SNP system in kdump path, if it fails to reserve old DTE
>> table, it tries to allocate new one! Looking into code again, it may be OK to
>> fail in that path as well.. so that we will have common flow.
> 
> If it allocates a new (empty) one and does a full flush of the iommu
> that would be OK?

I did look into the init sequence. We have kdump check everywhere which will
create issues. We will try to cleanup that path along with your suggestion to
remove flush from ste_dte_entry() code path. I will have separate series for that.


-Vasant