From: Ashish Kalra <ashish.kalra@amd.com>
When leaking certain page types, such as Hypervisor Fixed (HV_FIXED)
pages, it does not make sense to dump RMP contents for the 2MB range of
the page(s) being leaked. In the case of HV_FIXED pages, this is not an
error situation where the surrounding 2MB page RMP entries can provide
debug information.
Add new __snp_leak_pages() API with dump_rmp bool parameter to support
continue adding pages to the snp_leaked_pages_list but not issue
dump_rmpentry().
Make snp_leak_pages() a wrapper for the common case which also allows
existing users to continue to dump RMP entries.
Suggested-by: Thomas Lendacky <Thomas.Lendacky@amd.com>
Suggested-by: Sean Christopherson <seanjc@google.com>
Signed-off-by: Ashish Kalra <ashish.kalra@amd.com>
---
arch/x86/include/asm/sev.h | 8 +++++++-
arch/x86/virt/svm/sev.c | 7 ++++---
2 files changed, 11 insertions(+), 4 deletions(-)
diff --git a/arch/x86/include/asm/sev.h b/arch/x86/include/asm/sev.h
index 00475b814ac4..7a1ae990b15f 100644
--- a/arch/x86/include/asm/sev.h
+++ b/arch/x86/include/asm/sev.h
@@ -635,10 +635,15 @@ void snp_dump_hva_rmpentry(unsigned long address);
int psmash(u64 pfn);
int rmp_make_private(u64 pfn, u64 gpa, enum pg_level level, u32 asid, bool immutable);
int rmp_make_shared(u64 pfn, enum pg_level level);
-void snp_leak_pages(u64 pfn, unsigned int npages);
+void __snp_leak_pages(u64 pfn, unsigned int npages, bool dump_rmp);
void kdump_sev_callback(void);
void snp_fixup_e820_tables(void);
+static inline void snp_leak_pages(u64 pfn, unsigned int pages)
+{
+ __snp_leak_pages(pfn, pages, true);
+}
+
static inline void sev_evict_cache(void *va, int npages)
{
volatile u8 val __always_unused;
@@ -668,6 +673,7 @@ static inline int rmp_make_private(u64 pfn, u64 gpa, enum pg_level level, u32 as
return -ENODEV;
}
static inline int rmp_make_shared(u64 pfn, enum pg_level level) { return -ENODEV; }
+static inline void __snp_leak_pages(u64 pfn, unsigned int npages, bool dump_rmp) {}
static inline void snp_leak_pages(u64 pfn, unsigned int npages) {}
static inline void kdump_sev_callback(void) { }
static inline void snp_fixup_e820_tables(void) {}
diff --git a/arch/x86/virt/svm/sev.c b/arch/x86/virt/svm/sev.c
index 942372e69b4d..ee643a6cd691 100644
--- a/arch/x86/virt/svm/sev.c
+++ b/arch/x86/virt/svm/sev.c
@@ -1029,7 +1029,7 @@ int rmp_make_shared(u64 pfn, enum pg_level level)
}
EXPORT_SYMBOL_GPL(rmp_make_shared);
-void snp_leak_pages(u64 pfn, unsigned int npages)
+void __snp_leak_pages(u64 pfn, unsigned int npages, bool dump_rmp)
{
struct page *page = pfn_to_page(pfn);
@@ -1052,14 +1052,15 @@ void snp_leak_pages(u64 pfn, unsigned int npages)
(PageHead(page) && compound_nr(page) <= npages))
list_add_tail(&page->buddy_list, &snp_leaked_pages_list);
- dump_rmpentry(pfn);
+ if (dump_rmp)
+ dump_rmpentry(pfn);
snp_nr_leaked_pages++;
pfn++;
page++;
}
spin_unlock(&snp_leaked_pages_list_lock);
}
-EXPORT_SYMBOL_GPL(snp_leak_pages);
+EXPORT_SYMBOL_GPL(__snp_leak_pages);
void kdump_sev_callback(void)
{
--
2.34.1On Wed, Sep 10, 2025, Ashish Kalra wrote:
> diff --git a/arch/x86/include/asm/sev.h b/arch/x86/include/asm/sev.h
> index 00475b814ac4..7a1ae990b15f 100644
> --- a/arch/x86/include/asm/sev.h
> +++ b/arch/x86/include/asm/sev.h
> @@ -635,10 +635,15 @@ void snp_dump_hva_rmpentry(unsigned long address);
> int psmash(u64 pfn);
> int rmp_make_private(u64 pfn, u64 gpa, enum pg_level level, u32 asid, bool immutable);
> int rmp_make_shared(u64 pfn, enum pg_level level);
> -void snp_leak_pages(u64 pfn, unsigned int npages);
> +void __snp_leak_pages(u64 pfn, unsigned int npages, bool dump_rmp);
> void kdump_sev_callback(void);
> void snp_fixup_e820_tables(void);
>
> +static inline void snp_leak_pages(u64 pfn, unsigned int pages)
> +{
> + __snp_leak_pages(pfn, pages, true);
> +}
> +
> static inline void sev_evict_cache(void *va, int npages)
> {
> volatile u8 val __always_unused;
> @@ -668,6 +673,7 @@ static inline int rmp_make_private(u64 pfn, u64 gpa, enum pg_level level, u32 as
> return -ENODEV;
> }
> static inline int rmp_make_shared(u64 pfn, enum pg_level level) { return -ENODEV; }
> +static inline void __snp_leak_pages(u64 pfn, unsigned int npages, bool dump_rmp) {}
This stub is unnecessary. As pointed out elsewhere[*], I'm pretty sure all these
stubs are unnecessary.
Oof. Even worse, the stubs appear to be actively hiding bugs. The APIs are
guarded with CONFIG_KVM_AMD_SEV=y, but **KVM** doesn't call any of these outside
of SEV code. I.e. if *KVM* were the only user, the stubs would just be dead code.
But the below build failures show that they aren't dead code, which means that
kernels with CONFIG_KVM_AMD_SEV=n will silently (until something explodes) do the
wrong thing, because the stubs are hiding the missing dependencies.
arch/x86/boot/startup/sev-shared.c: In function ‘pvalidate_4k_page’:
arch/x86/boot/startup/sev-shared.c:820:17: error: implicit declaration of function ‘sev_evict_cache’ [-Wimplicit-function-declaration]
820 | sev_evict_cache((void *)vaddr, 1);
| ^~~~~~~~~~~~~~~
AR arch/x86/realmode/built-in.a
arch/x86/coco/sev/core.c: In function ‘pvalidate_pages’:
arch/x86/coco/sev/core.c:386:25: error: implicit declaration of function ‘sev_evict_cache’ [-Wimplicit-function-declaration]
386 | sev_evict_cache(pfn_to_kaddr(e->gfn), e->pagesize ? 512 : 1);
| ^~~~~~~~~~~~~~~
arch/x86/mm/mem_encrypt.c: In function ‘mem_encrypt_setup_arch’:
arch/x86/mm/mem_encrypt.c:112:17: error: implicit declaration of function ‘snp_fixup_e820_tables’ [-Wimplicit-function-declaration]
112 | snp_fixup_e820_tables();
| ^~~~~~~~~~~~~~~~~~~~~
arch/x86/mm/fault.c: In function ‘show_fault_oops’:
arch/x86/mm/fault.c:587:17: error: implicit declaration of function ‘snp_dump_hva_rmpentry’ [-Wimplicit-function-declaration]
587 | snp_dump_hva_rmpentry(address);
| ^~~~~~~~~~~~~~~~~~~~~
arch/x86/kernel/cpu/amd.c: In function ‘bsp_determine_snp’:
arch/x86/kernel/cpu/amd.c:370:21: error: implicit declaration of function ‘snp_probe_rmptable_info’ [-Wimplicit-function-declaration]
370 | snp_probe_rmptable_info()) {
| ^~~~~~~~~~~~~~~~~~~~~~~
AR drivers/iommu/amd/built-in.a
AR drivers/iommu/built-in.a
AR drivers/built-in.a
[*] https://lore.kernel.org/all/aMHP5EO-ucJGdHXz@google.com
On 9/12/25 13:34, Sean Christopherson wrote:
> On Wed, Sep 10, 2025, Ashish Kalra wrote:
>> diff --git a/arch/x86/include/asm/sev.h b/arch/x86/include/asm/sev.h
>> index 00475b814ac4..7a1ae990b15f 100644
>> --- a/arch/x86/include/asm/sev.h
>> +++ b/arch/x86/include/asm/sev.h
>> @@ -635,10 +635,15 @@ void snp_dump_hva_rmpentry(unsigned long address);
>> int psmash(u64 pfn);
>> int rmp_make_private(u64 pfn, u64 gpa, enum pg_level level, u32 asid, bool immutable);
>> int rmp_make_shared(u64 pfn, enum pg_level level);
>> -void snp_leak_pages(u64 pfn, unsigned int npages);
>> +void __snp_leak_pages(u64 pfn, unsigned int npages, bool dump_rmp);
>> void kdump_sev_callback(void);
>> void snp_fixup_e820_tables(void);
>>
>> +static inline void snp_leak_pages(u64 pfn, unsigned int pages)
>> +{
>> + __snp_leak_pages(pfn, pages, true);
>> +}
>> +
>> static inline void sev_evict_cache(void *va, int npages)
>> {
>> volatile u8 val __always_unused;
>> @@ -668,6 +673,7 @@ static inline int rmp_make_private(u64 pfn, u64 gpa, enum pg_level level, u32 as
>> return -ENODEV;
>> }
>> static inline int rmp_make_shared(u64 pfn, enum pg_level level) { return -ENODEV; }
>> +static inline void __snp_leak_pages(u64 pfn, unsigned int npages, bool dump_rmp) {}
>
> This stub is unnecessary. As pointed out elsewhere[*], I'm pretty sure all these
> stubs are unnecessary.
>
> Oof. Even worse, the stubs appear to be actively hiding bugs. The APIs are
> guarded with CONFIG_KVM_AMD_SEV=y, but **KVM** doesn't call any of these outside
> of SEV code. I.e. if *KVM* were the only user, the stubs would just be dead code.
>
> But the below build failures show that they aren't dead code, which means that
> kernels with CONFIG_KVM_AMD_SEV=n will silently (until something explodes) do the
> wrong thing, because the stubs are hiding the missing dependencies.
>
> arch/x86/boot/startup/sev-shared.c: In function ‘pvalidate_4k_page’:
> arch/x86/boot/startup/sev-shared.c:820:17: error: implicit declaration of function ‘sev_evict_cache’ [-Wimplicit-function-declaration]
> 820 | sev_evict_cache((void *)vaddr, 1);
Yeah, this one is on me. sev_evict_cache() is guest code and should be
under the CONFIG_AMD_MEM_ENCRYPT #ifdef.
> | ^~~~~~~~~~~~~~~
> AR arch/x86/realmode/built-in.a
> arch/x86/coco/sev/core.c: In function ‘pvalidate_pages’:
> arch/x86/coco/sev/core.c:386:25: error: implicit declaration of function ‘sev_evict_cache’ [-Wimplicit-function-declaration]
> 386 | sev_evict_cache(pfn_to_kaddr(e->gfn), e->pagesize ? 512 : 1);
> | ^~~~~~~~~~~~~~~
> arch/x86/mm/mem_encrypt.c: In function ‘mem_encrypt_setup_arch’:
> arch/x86/mm/mem_encrypt.c:112:17: error: implicit declaration of function ‘snp_fixup_e820_tables’ [-Wimplicit-function-declaration]
> 112 | snp_fixup_e820_tables();
This function is only meant to be used if we're going to run SEV guests,
so being guarded by CONFIG_KVM_AMD_SEV was on purpose. I'm just not sure
why the stub didn't get used... or did you remove them?
> | ^~~~~~~~~~~~~~~~~~~~~
> arch/x86/mm/fault.c: In function ‘show_fault_oops’:
> arch/x86/mm/fault.c:587:17: error: implicit declaration of function ‘snp_dump_hva_rmpentry’ [-Wimplicit-function-declaration]
> 587 | snp_dump_hva_rmpentry(address);
Ditto here.
> | ^~~~~~~~~~~~~~~~~~~~~
> arch/x86/kernel/cpu/amd.c: In function ‘bsp_determine_snp’:
> arch/x86/kernel/cpu/amd.c:370:21: error: implicit declaration of function ‘snp_probe_rmptable_info’ [-Wimplicit-function-declaration]
> 370 | snp_probe_rmptable_info()) {
and here.
Thanks,
Tom
> | ^~~~~~~~~~~~~~~~~~~~~~~
> AR drivers/iommu/amd/built-in.a
> AR drivers/iommu/built-in.a
> AR drivers/built-in.a
>
> [*] https://lore.kernel.org/all/aMHP5EO-ucJGdHXz@google.com
On Fri, Sep 12, 2025, Tom Lendacky wrote: > On 9/12/25 13:34, Sean Christopherson wrote: > > But the below build failures show that they aren't dead code, which means that > > kernels with CONFIG_KVM_AMD_SEV=n will silently (until something explodes) do the > > wrong thing, because the stubs are hiding the missing dependencies. > > > > arch/x86/boot/startup/sev-shared.c: In function ‘pvalidate_4k_page’: > > arch/x86/boot/startup/sev-shared.c:820:17: error: implicit declaration of function ‘sev_evict_cache’ [-Wimplicit-function-declaration] > > 820 | sev_evict_cache((void *)vaddr, 1); > > Yeah, this one is on me. sev_evict_cache() is guest code and should be > under the CONFIG_AMD_MEM_ENCRYPT #ifdef. > > > | ^~~~~~~~~~~~~~~ > > AR arch/x86/realmode/built-in.a > > arch/x86/coco/sev/core.c: In function ‘pvalidate_pages’: > > arch/x86/coco/sev/core.c:386:25: error: implicit declaration of function ‘sev_evict_cache’ [-Wimplicit-function-declaration] > > 386 | sev_evict_cache(pfn_to_kaddr(e->gfn), e->pagesize ? 512 : 1); > > | ^~~~~~~~~~~~~~~ > > arch/x86/mm/mem_encrypt.c: In function ‘mem_encrypt_setup_arch’: > > arch/x86/mm/mem_encrypt.c:112:17: error: implicit declaration of function ‘snp_fixup_e820_tables’ [-Wimplicit-function-declaration] > > 112 | snp_fixup_e820_tables(); > > This function is only meant to be used if we're going to run SEV guests, > so being guarded by CONFIG_KVM_AMD_SEV was on purpose. I'm just not sure > why the stub didn't get used... or did you remove them? I removed all the stubs to see what would break (I was expecting nothing since all of KVM's accesses are gated by CONFIG_KVM_AMD_SEV).
On 9/12/25 14:41, Sean Christopherson wrote: > On Fri, Sep 12, 2025, Tom Lendacky wrote: >> On 9/12/25 13:34, Sean Christopherson wrote: >>> But the below build failures show that they aren't dead code, which means that >>> kernels with CONFIG_KVM_AMD_SEV=n will silently (until something explodes) do the >>> wrong thing, because the stubs are hiding the missing dependencies. >>> >>> arch/x86/boot/startup/sev-shared.c: In function ‘pvalidate_4k_page’: >>> arch/x86/boot/startup/sev-shared.c:820:17: error: implicit declaration of function ‘sev_evict_cache’ [-Wimplicit-function-declaration] >>> 820 | sev_evict_cache((void *)vaddr, 1); >> >> Yeah, this one is on me. sev_evict_cache() is guest code and should be >> under the CONFIG_AMD_MEM_ENCRYPT #ifdef. >> >>> | ^~~~~~~~~~~~~~~ >>> AR arch/x86/realmode/built-in.a >>> arch/x86/coco/sev/core.c: In function ‘pvalidate_pages’: >>> arch/x86/coco/sev/core.c:386:25: error: implicit declaration of function ‘sev_evict_cache’ [-Wimplicit-function-declaration] >>> 386 | sev_evict_cache(pfn_to_kaddr(e->gfn), e->pagesize ? 512 : 1); >>> | ^~~~~~~~~~~~~~~ >>> arch/x86/mm/mem_encrypt.c: In function ‘mem_encrypt_setup_arch’: >>> arch/x86/mm/mem_encrypt.c:112:17: error: implicit declaration of function ‘snp_fixup_e820_tables’ [-Wimplicit-function-declaration] >>> 112 | snp_fixup_e820_tables(); >> >> This function is only meant to be used if we're going to run SEV guests, >> so being guarded by CONFIG_KVM_AMD_SEV was on purpose. I'm just not sure >> why the stub didn't get used... or did you remove them? > > I removed all the stubs to see what would break (I was expecting nothing since > all of KVM's accesses are gated by CONFIG_KVM_AMD_SEV). Ah, ok. During the SNP host/hypervisor enablement there was feedback about doing all the RMP type stuff based on whether the kernel could run SNP guests. So that's why we see things outside of the KVM tree using CONFIG_KVM_AMD_SEV. Thanks, Tom
On Wed, Sep 10, 2025 at 10:55:24PM +0000, Ashish Kalra wrote:
> From: Ashish Kalra <ashish.kalra@amd.com>
>
> When leaking certain page types, such as Hypervisor Fixed (HV_FIXED)
> pages, it does not make sense to dump RMP contents for the 2MB range of
> the page(s) being leaked. In the case of HV_FIXED pages, this is not an
> error situation where the surrounding 2MB page RMP entries can provide
> debug information.
>
> Add new __snp_leak_pages() API with dump_rmp bool parameter to support
> continue adding pages to the snp_leaked_pages_list but not issue
> dump_rmpentry().
>
> Make snp_leak_pages() a wrapper for the common case which also allows
> existing users to continue to dump RMP entries.
>
> Suggested-by: Thomas Lendacky <Thomas.Lendacky@amd.com>
> Suggested-by: Sean Christopherson <seanjc@google.com>
> Signed-off-by: Ashish Kalra <ashish.kalra@amd.com>
> ---
> arch/x86/include/asm/sev.h | 8 +++++++-
> arch/x86/virt/svm/sev.c | 7 ++++---
> 2 files changed, 11 insertions(+), 4 deletions(-)
Sean, lemme know if I should carry this through tip.
Or, if you wanna take it:
Acked-by: Borislav Petkov (AMD) <bp@alien8.de>
--
Regards/Gruss,
Boris.
https://people.kernel.org/tglx/notes-about-netiquette
On Fri, Sep 12, 2025, Borislav Petkov wrote: > On Wed, Sep 10, 2025 at 10:55:24PM +0000, Ashish Kalra wrote: > > From: Ashish Kalra <ashish.kalra@amd.com> > > > > When leaking certain page types, such as Hypervisor Fixed (HV_FIXED) > > pages, it does not make sense to dump RMP contents for the 2MB range of > > the page(s) being leaked. In the case of HV_FIXED pages, this is not an > > error situation where the surrounding 2MB page RMP entries can provide > > debug information. > > > > Add new __snp_leak_pages() API with dump_rmp bool parameter to support > > continue adding pages to the snp_leaked_pages_list but not issue > > dump_rmpentry(). > > > > Make snp_leak_pages() a wrapper for the common case which also allows > > existing users to continue to dump RMP entries. > > > > Suggested-by: Thomas Lendacky <Thomas.Lendacky@amd.com> > > Suggested-by: Sean Christopherson <seanjc@google.com> > > Signed-off-by: Ashish Kalra <ashish.kalra@amd.com> > > --- > > arch/x86/include/asm/sev.h | 8 +++++++- > > arch/x86/virt/svm/sev.c | 7 ++++--- > > 2 files changed, 11 insertions(+), 4 deletions(-) > > Sean, lemme know if I should carry this through tip. Take them through tip, but the stubs mess in sev.h really needs to be cleaned up (doesn't have to block this series, but should be done sooner than later).
On Fri, Sep 12, 2025 at 11:34:45AM -0700, Sean Christopherson wrote:
> On Fri, Sep 12, 2025, Borislav Petkov wrote:
> > On Wed, Sep 10, 2025 at 10:55:24PM +0000, Ashish Kalra wrote:
> > > From: Ashish Kalra <ashish.kalra@amd.com>
> > >
> > > When leaking certain page types, such as Hypervisor Fixed (HV_FIXED)
> > > pages, it does not make sense to dump RMP contents for the 2MB range of
> > > the page(s) being leaked. In the case of HV_FIXED pages, this is not an
> > > error situation where the surrounding 2MB page RMP entries can provide
> > > debug information.
> > >
> > > Add new __snp_leak_pages() API with dump_rmp bool parameter to support
> > > continue adding pages to the snp_leaked_pages_list but not issue
> > > dump_rmpentry().
> > >
> > > Make snp_leak_pages() a wrapper for the common case which also allows
> > > existing users to continue to dump RMP entries.
> > >
> > > Suggested-by: Thomas Lendacky <Thomas.Lendacky@amd.com>
> > > Suggested-by: Sean Christopherson <seanjc@google.com>
> > > Signed-off-by: Ashish Kalra <ashish.kalra@amd.com>
> > > ---
> > > arch/x86/include/asm/sev.h | 8 +++++++-
> > > arch/x86/virt/svm/sev.c | 7 ++++---
> > > 2 files changed, 11 insertions(+), 4 deletions(-)
> >
> > Sean, lemme know if I should carry this through tip.
>
> Take them through tip, but the stubs mess in sev.h really needs to be cleaned up
> (doesn't have to block this series, but should be done sooner than later).
Right, I guess Tom's on that one...
As to the other two:
https://lore.kernel.org/r/e7807012187bdda8d76ab408b87f15631461993d.1757543774.git.ashish.kalra@amd.com
https://lore.kernel.org/r/7be1accd4c0968fe04d6efe6ebb0185d77bed129.1757543774.git.ashish.kalra@amd.com
Herbert, how do you want to proceed here?
Do you want me to give you an immutable branch with the first patch and you
can base the other two ontop or should I carry all three through tip?
Yeah, it is time for patch tetris again... :-P
Thx.
--
Regards/Gruss,
Boris.
https://people.kernel.org/tglx/notes-about-netiquette
On Sat, Sep 13, 2025 at 12:55:28PM +0200, Borislav Petkov wrote: > > Right, I guess Tom's on that one... > > As to the other two: > > https://lore.kernel.org/r/e7807012187bdda8d76ab408b87f15631461993d.1757543774.git.ashish.kalra@amd.com > https://lore.kernel.org/r/7be1accd4c0968fe04d6efe6ebb0185d77bed129.1757543774.git.ashish.kalra@amd.com > > Herbert, how do you want to proceed here? > > Do you want me to give you an immutable branch with the first patch and you > can base the other two ontop or should I carry all three through tip? > > Yeah, it is time for patch tetris again... :-P Hi Boris: You can take those two patches directly with my ack: Acked-by: Herbert Xu <herbert@gondor.apana.org.au> Thanks, -- Email: Herbert Xu <herbert@gondor.apana.org.au> Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
On Tue, Sep 16, 2025 at 11:51:51AM +0800, Herbert Xu wrote:
> You can take those two patches directly with my ack:
>
> Acked-by: Herbert Xu <herbert@gondor.apana.org.au>
Cool, thanks Herbert.
--
Regards/Gruss,
Boris.
https://people.kernel.org/tglx/notes-about-netiquette
On 9/10/25 17:55, Ashish Kalra wrote:
> From: Ashish Kalra <ashish.kalra@amd.com>
>
> When leaking certain page types, such as Hypervisor Fixed (HV_FIXED)
> pages, it does not make sense to dump RMP contents for the 2MB range of
> the page(s) being leaked. In the case of HV_FIXED pages, this is not an
> error situation where the surrounding 2MB page RMP entries can provide
> debug information.
>
> Add new __snp_leak_pages() API with dump_rmp bool parameter to support
> continue adding pages to the snp_leaked_pages_list but not issue
> dump_rmpentry().
>
> Make snp_leak_pages() a wrapper for the common case which also allows
> existing users to continue to dump RMP entries.
>
> Suggested-by: Thomas Lendacky <Thomas.Lendacky@amd.com>
> Suggested-by: Sean Christopherson <seanjc@google.com>
> Signed-off-by: Ashish Kalra <ashish.kalra@amd.com>
Reviewed-by: Tom Lendacky <thomas.lendacky@amd.com>
> ---
> arch/x86/include/asm/sev.h | 8 +++++++-
> arch/x86/virt/svm/sev.c | 7 ++++---
> 2 files changed, 11 insertions(+), 4 deletions(-)
>
> diff --git a/arch/x86/include/asm/sev.h b/arch/x86/include/asm/sev.h
> index 00475b814ac4..7a1ae990b15f 100644
> --- a/arch/x86/include/asm/sev.h
> +++ b/arch/x86/include/asm/sev.h
> @@ -635,10 +635,15 @@ void snp_dump_hva_rmpentry(unsigned long address);
> int psmash(u64 pfn);
> int rmp_make_private(u64 pfn, u64 gpa, enum pg_level level, u32 asid, bool immutable);
> int rmp_make_shared(u64 pfn, enum pg_level level);
> -void snp_leak_pages(u64 pfn, unsigned int npages);
> +void __snp_leak_pages(u64 pfn, unsigned int npages, bool dump_rmp);
> void kdump_sev_callback(void);
> void snp_fixup_e820_tables(void);
>
> +static inline void snp_leak_pages(u64 pfn, unsigned int pages)
> +{
> + __snp_leak_pages(pfn, pages, true);
> +}
> +
> static inline void sev_evict_cache(void *va, int npages)
> {
> volatile u8 val __always_unused;
> @@ -668,6 +673,7 @@ static inline int rmp_make_private(u64 pfn, u64 gpa, enum pg_level level, u32 as
> return -ENODEV;
> }
> static inline int rmp_make_shared(u64 pfn, enum pg_level level) { return -ENODEV; }
> +static inline void __snp_leak_pages(u64 pfn, unsigned int npages, bool dump_rmp) {}
> static inline void snp_leak_pages(u64 pfn, unsigned int npages) {}
> static inline void kdump_sev_callback(void) { }
> static inline void snp_fixup_e820_tables(void) {}
> diff --git a/arch/x86/virt/svm/sev.c b/arch/x86/virt/svm/sev.c
> index 942372e69b4d..ee643a6cd691 100644
> --- a/arch/x86/virt/svm/sev.c
> +++ b/arch/x86/virt/svm/sev.c
> @@ -1029,7 +1029,7 @@ int rmp_make_shared(u64 pfn, enum pg_level level)
> }
> EXPORT_SYMBOL_GPL(rmp_make_shared);
>
> -void snp_leak_pages(u64 pfn, unsigned int npages)
> +void __snp_leak_pages(u64 pfn, unsigned int npages, bool dump_rmp)
> {
> struct page *page = pfn_to_page(pfn);
>
> @@ -1052,14 +1052,15 @@ void snp_leak_pages(u64 pfn, unsigned int npages)
> (PageHead(page) && compound_nr(page) <= npages))
> list_add_tail(&page->buddy_list, &snp_leaked_pages_list);
>
> - dump_rmpentry(pfn);
> + if (dump_rmp)
> + dump_rmpentry(pfn);
> snp_nr_leaked_pages++;
> pfn++;
> page++;
> }
> spin_unlock(&snp_leaked_pages_list_lock);
> }
> -EXPORT_SYMBOL_GPL(snp_leak_pages);
> +EXPORT_SYMBOL_GPL(__snp_leak_pages);
>
> void kdump_sev_callback(void)
> {
© 2016 - 2025 Red Hat, Inc.