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

On 8/18/26 01:45, Vasant Hegde wrote:
> 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?

Not knowing what the physical address is or what the RMP state is, I
would have to speculate a bit. I wonder if the memory is now PMD aligned
and marked as a 2M page? In iommu_page_make_shared() there is an
explicit check for the level of the page being made shared being greater
than PG_LEVEL_4K. If it is greater than 4K it does a psmash() and then
continues. However, this check is only done if the PFN is not on a 2M
boundary. That could result in RMPUPDATE returning FAIL_OVERLAP if the
RMP has the range marked as 2M but the request is for a 4K page.

What happens if you always take the if path iommu_page_make_shared()?
@Usama, could you try making that modification and see if that helps?

Thanks,
Tom
> 
>>
>> 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
> 
>