Re: [PATCH 0/2] iommu/amd: Use MAX buffer size when SNP is enabled on Family 0x19

Hi Usama,


On 8/17/2026 9:36 PM, Usama Arif wrote:
> On Thu, 13 Aug 2026 19:28:55 +0530 Vasant Hegde <[email protected]> wrote:
> 
>> Usama,
>>
>> On 8/13/2026 6:48 PM, Usama Arif wrote:
>>> [You don't often get email from [email protected]. Learn why this is important at https://aka.ms/LearnAboutSenderIdentification ]
>>>
>>> On Mon, 20 Apr 2026 08:42:02 +0000 Vasant Hegde <[email protected]> wrote:
>>>
>>>> This series addresses CVE-2023-20585 [1] by increasing the AMD IOMMU
>>>> Event log and PPR log buffer sizes to the maximum supported value (512K)
>>>> on affected CPU families when SNP is enabled.
>>>>
>>>> Use MAX buffer size when SNP is enabled on Milan/Genoa. Impacted buffers:
>>>>   - Milan : Event log (PPR/GALog is not supported when SNP is enabled)
>>>>   - Genoa : Event and PPR log (GALog is not supported when SNP is enabled)
>>>>
>>>
>>> Hi,
>>>
>>> This series seems to break kexec in our production on Milan hosts with SEV enabled.
>>> This is on the 6.18.43 stable kernel backport.
>>
>> Do you have dmesg?
>>
>>>
>>> If on top of 6.18.43 release, we revert the 2 commits, i.e.
>>> Revert "iommu/amd: Use maximum PPR log buffer size when SNP is enabled on Family 0x19"
>>> Revert "iommu/amd: Use maximum Event log buffer size when SNP is enabled on Family 0x19"
>>>
>>> kexec starts working again.
>>>> Could you help in fixing this issue?
>>
>> Sure. We will try to reproduce it internally and get back to you.
> 
> Hi,
> 
> Just following up, were you able to reproduce this?

So far no luck with SEV and SEV/SNP.

> 
> I was able to trace down the hang to this do while loop [1].

In allocation path, we explicitly set 4K pages (iommu_alloc_4k_pages()).

If SNP is enabled in host, then in shutdown path, amd_iommu_snp_disable() gets
called and it tries to mark event log memory as shared. In this path, it calls
rmpupdate. But I can't think of reason for it to hang in the rmpupdate loop.

@Tom, Ashish, Any idea?

> 
> Could this be a firmware bug? We are currently running 1.53 (below
> shows up in the dmesg).
> 
> [   22.245942] ccp 0000:41:00.1: SEV-SNP API:1.53 build:5
> [   22.308933] ccp 0000:41:00.1: SEV API:1.53 build:5

We are on

[   24.783307] ccp 0000:46:00.1: SEV-SNP API:1.55 build:29
[   24.844646] ccp 0000:46:00.1: SEV API:1.55 build:29

Is it possible to upgrade BIOS and verify?


Can you please share the dmesg of the booted system (before doing the kexec)?

-Vasant