From: Ashish Kalra
When the shared pages are being made private during kdump preparation
there are additional checks to handle shared GHCB pages.
These additional checks include handling the case of GHCB page being
contained within a huge page.
The check for handling the case of GHCB contained
From: Ashish Kalra
When the shared pages are being made private during kdump preparation
there are additional checks to handle shared GHCB pages.
These additional checks include handling the case of GHCB page being
contained within a huge page.
The check for handling the case of GHCB contained
From: Ashish Kalra
When the shared pages are being made private during kdump preparation
there are additional checks to handle shared GHCB pages.
These additional checks include handling the case of GHCB page being
contained within a huge page.
The check for handling the case of GHCB contained
From: Ashish Kalra
When the shared pages are being made private during kdump preparation
there are additional checks to handle shared GHCB pages.
These additional checks include handling the case of GHCB page being
contained within a huge page.
While handling the case of GHCB page contained
From: Ashish Kalra
When kdump is running makedumpfile to generate vmcore and dumping SNP
guest memory it touches the VMSA page of the vCPU executing kdump which
then results in unrecoverable #NPF/RMP faults as the VMSA page is
marked busy/in-use when the vCPU is running and subsequently causes
From: Ashish Kalra
When kdump is running makedumpfile to generate vmcore and dumping SNP
guest memory it touches the VMSA page of the vCPU executing kdump which
then results in unrecoverable #NPF/RMP faults as the VMSA page is
marked busy/in-use when the vCPU is running and subsequently causes
From: Ashish Kalra
When the shared pages are being made private during kdump preparation
there are additional checks to handle shared GHCB pages.
These additional checks include handling the case of GHCB page being
contained within a huge page.
There is a bug in this additional check for GHCB
From: Ashish Kalra
When the shared pages are being made private during kdump preparation
there are additional checks to handle shared GHCB pages.
These additional checks include handling the case of GHCB page being
contained within a 2MB page.
There is a bug in this additional check for GHCB
From: Ashish Kalra
When kdump is running makedumpfile to generate vmcore and dumping SNP
guest memory it touches the VMSA page of the vCPU executing kdump which
then results in unrecoverable #NPF/RMP faults as the VMSA page is
marked busy/in-use when the vCPU is running.
This leads to guest
From: Ashish Kalra
[ 117.111097] watchdog: BUG: soft lockup - CPU#0 stuck for 27s! [cp:318]
[ 117.15] Modules linked in:
[ 117.20] irq event stamp: 3066414
[ 117.22] hardirqs last enabled at (3066413): []
irqentry_exit+0x39/0x90
[ 117.42] hardirqs last disabled at (3066414
> On Thu, Feb 13, 2025 at 07:55:15AM -0800, Dave Hansen wrote:
>> On 1/13/25 06:59, Eric W. Biederman wrote:
>> ...
>> > I have a new objection. I believe ``unaccepted memory'' and especially
>> > lazily initialized ``unaccepted memory'' is an information leak that
>> > could defeat the purpose of
Hello Sean,
On 9/4/2024 5:23 PM, Sean Christopherson wrote:
>> On Wed, Sep 04, 2024, Ashish Kalra wrote:
>>> On 9/4/2024 2:54 PM, Michael Roth wrote:
>>>> - Sean inquired about making the target kdump kernel more agnostic to
>>>> whether or not SNP
Hello Sean,
On 9/4/2024 5:23 PM, Sean Christopherson wrote:
>> On Wed, Sep 04, 2024, Ashish Kalra wrote:
>>> On 9/4/2024 2:54 PM, Michael Roth wrote:
>>>> - Sean inquired about making the target kdump kernel more agnostic to
>>>> whether or not SNP
Hello Sean,
On 9/4/2024 5:23 PM, Sean Christopherson wrote:
> On Wed, Sep 04, 2024, Ashish Kalra wrote:
>> On 9/4/2024 2:54 PM, Michael Roth wrote:
>>> - Sean inquired about making the target kdump kernel more agnostic to
>>> whether or not SNP_SHUTDOWN was done
From: Ashish Kalra
With active SNP VMs, SNP_SHUTDOWN_EX invoked during panic notifiers causes
crashkernel boot failure with the following signature:
[ 563.497112] sysrq: Trigger a crash
[ 563.508415] Kernel panic - not syncing: sysrq triggered crash
[ 563.522002] CPU: 10 UID: 0 PID: 4661
From: Ashish Kalra
With active SNP VMs, SNP_SHUTDOWN_EX invoked during panic notifiers causes
crashkernel boot failure with the following signature:
[ 563.497112] sysrq: Trigger a crash
[ 563.508415] Kernel panic - not syncing: sysrq triggered crash
[ 563.522002] CPU: 10 UID: 0 PID: 4661
From: Ashish Kalra
Refactor __set_clr_pte_enc() and add two new helper functions to
set/clear PTE C-bit from early SEV/SNP initialization code and
later during shutdown/kexec especially when all CPUs are stopped
and interrupts are disabled and set_memory_xx() interfaces can't
be used
From: Ashish Kalra
SNP guests allocate shared buffers to perform I/O. It is done by
allocating pages normally from the buddy allocator and converting them
to shared with set_memory_decrypted().
The second, kexec-ed, kernel has no idea what memory is converted this way.
It only sees
From: Ashish Kalra
Accessing guest video memory/RAM in the decompressor causes guest
termination as the boot stage2 #VC handler for SEV-ES/SNP systems does
not support MMIO handling.
This issue is observed during a SEV-ES/SNP guest kexec as kexec -c adds
screen_info to the boot parameters
From: Ashish Kalra
The patchset adds bits and pieces to get kexec (and crashkernel) work on
SNP guest.
This patchset requires the following fix for preventing EFI memory map
corruption while doing SNP guest kexec:
https://lore.kernel.org/all/16131a10-b473-41cc-a96e-d71a4d930...@amd.com/T
From: Ashish Kalra
SNP guests allocate shared buffers to perform I/O. It is done by
allocating pages normally from the buddy allocator and converting them
to shared with set_memory_decrypted().
The second, kexec-ed, kernel has no idea what memory is converted this way.
It only sees
From: Ashish Kalra
Refactor __set_clr_pte_enc() and add two new helper functions to
set/clear PTE C-bit from early SEV/SNP initialization code and
later during shutdown/kexec especially when all CPUs are stopped
and interrupts are disabled and set_memory_xx() interfaces can't
be used
From: Ashish Kalra
Accessing guest video memory/RAM in the decompressor causes guest
termination as the boot stage2 #VC handler for SEV-ES/SNP systems does
not support MMIO handling.
This issue is observed during a SEV-ES/SNP guest kexec as kexec -c adds
screen_info to the boot parameters
From: Ashish Kalra
The patchset adds bits and pieces to get kexec (and crashkernel) work on
SNP guest.
This patchset requires the following fix for preventing EFI memory map
corruption while doing SNP guest kexec:
https://lore.kernel.org/all/16131a10-b473-41cc-a96e-d71a4d930...@amd.com/T
From: Ashish Kalra
Accessing guest video memory/RAM in the decompressor causes guest
termination as the boot stage2 #VC handler for SEV-ES/SNP systems does
not support MMIO handling.
This issue is observed during a SEV-ES/SNP guest kexec as kexec -c adds
screen_info to the boot parameters
From: Ashish Kalra
SNP guests allocate shared buffers to perform I/O. It is done by
allocating pages normally from the buddy allocator and converting them
to shared with set_memory_decrypted().
The second, kexec-ed, kernel has no idea what memory is converted this way.
It only sees
From: Ashish Kalra
Refactor __set_clr_pte_enc() and add two new helper functions to
set/clear PTE C-bit from early SEV/SNP initialization code and
later during normal system operations and shutdown/kexec.
Signed-off-by: Ashish Kalra
---
arch/x86/include/asm/sev.h| 9 +++
arch/x86/mm
From: Ashish Kalra
The patchset adds bits and pieces to get kexec (and crashkernel) work on
SNP guest.
This patchset requires the following fix for preventing EFI memory map
corruption while doing SNP guest kexec:
https://lore.kernel.org/all/16131a10-b473-41cc-a96e-d71a4d930...@amd.com/T
From: Ashish Kalra
SNP guests allocate shared buffers to perform I/O. It is done by
allocating pages normally from the buddy allocator and converting them
to shared with set_memory_decrypted().
The second kernel has no idea what memory is converted this way. It only
sees E820_TYPE_RAM
From: Ashish Kalra
The patchset adds bits and pieces to get kexec (and crashkernel) work on
SNP guest.
This patchset requires the following fix for preventing EFI memory map
corruption while doing SNP guest kexec:
https://lore.kernel.org/all/16131a10-b473-41cc-a96e-d71a4d930...@amd.com/T
From: Ashish Kalra
Accessing guest video memory/RAM in the decompressor causes guest
termination as the boot stage2 #VC handler for SEV-ES/SNP systems does
not support MMIO handling.
This issue is observed during a SEV-ES/SNP guest kexec as kexec -c adds
screen_info to the boot parameters
From: Ashish Kalra
Accessing guest video memory/RAM in the decompressor causes guest
termination as the boot stage2 #VC handler for SEV-ES/SNP systems does
not support MMIO handling.
This issue is observed during a SEV-ES/SNP guest kexec as kexec -c adds
screen_info to the boot parameters
From: Ashish Kalra
SNP guests allocate shared buffers to perform I/O. It is done by
allocating pages normally from the buddy allocator and converting them
to shared with set_memory_decrypted().
The second kernel has no idea what memory is converted this way. It only
sees E820_TYPE_RAM
ind time
to do so. So lemme do it. If people have trouble converting their
ongoing featuritis patches, ask me for a sed script.
No functional changes.
Cc: Ashish Kalra
Cc: Joerg Roedel
Cc: Michael Roth
Cc: Nikunj A Dadhania
Cc: Tom Lendacky
Signed-off-by: Borislav Petkov (AMD)
---
From: Ashish Kalra
The patchset adds bits and pieces to get kexec (and crashkernel) work on
SNP guest.
This patchset requires the following fix for preventing EFI memory map
corruption while doing SNP guest kexec:
https://lore.kernel.org/all/16131a10-b473-41cc-a96e-d71a4d930...@amd.com/T
From: Ashish Kalra
SNP guests allocate shared buffers to perform I/O. It is done by
allocating pages normally from the buddy allocator and converting them
to shared with set_memory_decrypted().
The second kernel has no idea what memory is converted this way. It only
sees E820_TYPE_RAM
From: Ashish Kalra
Accessing guest video memory/RAM during kernel decompressor
causes guest termination as boot stage2 #VC handler for
SEV-ES/SNP systems does not support MMIO handling.
This issue is observed with SEV-ES/SNP guest kexec as
kexec -c adds screen_info to the boot parameters
passed
From: Ashish Kalra
The patchset adds bits and pieces to get kexec (and crashkernel) work on
SNP guest.
This patchset requires the following fix for preventing EFI memory map
corruption while doing SNP guest kexec:
https://lore.kernel.org/all/16131a10-b473-41cc-a96e-d71a4d930...@amd.com/T
From: Ashish Kalra
The patchset adds bits and pieces to get kexec (and crashkernel) work on
SNP guest.
The series is based off of and tested against Kirill Shutemov's tree:
https://github.com/intel/tdx.git guest-kexec
v7:
- Rebased onto current tip/master;
- Moved back to checkin
From: Ashish Kalra
SNP guests allocate shared buffers to perform I/O. It is done by
allocating pages normally from the buddy allocator and converting them
to shared with set_memory_decrypted().
The second kernel has no idea what memory is converted this way. It only
sees E820_TYPE_RAM
From: Ashish Kalra
Accessing guest video memory/RAM during kernel decompressor
causes guest termination as boot stage2 #VC handler for
SEV-ES/SNP systems does not support MMIO handling.
This issue is observed with SEV-ES/SNP guest kexec as
kexec -c adds screen_info to the boot parameters
passed
From: Ashish Kalra
With SNP guest kexec observe the following efi memmap corruption :
[0.00] efi: EFI v2.7 by EDK II
[0.00] efi: SMBIOS=0x7e33f000 SMBIOS 3.0=0x7e33d000 ACPI=0x7e57e000
ACPI 2.0=0x7e57e014 MEMATTR=0x7cc3c018 Unaccepted=0x7c09e018
[0.00] efi: [Firmware
From: Ashish Kalra
SNP guests allocate shared buffers to perform I/O. It is done by
allocating pages normally from the buddy allocator and converting them
to shared with set_memory_decrypted().
The second kernel has no idea what memory is converted this way. It only
sees E820_TYPE_RAM
From: Ashish Kalra
Accessing guest video memory/RAM during kernel decompressor
causes guest termination as boot stage2 #VC handler for
SEV-ES/SNP systems does not support MMIO handling.
This issue is observed with SEV-ES/SNP guest kexec as
kexec -c adds screen_info to the boot parameters
passed
From: Ashish Kalra
With SNP guest kexec observe the following efi memmap corruption :
[0.00] efi: EFI v2.7 by EDK II
[0.00] efi: SMBIOS=0x7e33f000 SMBIOS 3.0=0x7e33d000 ACPI=0x7e57e000
ACPI 2.0=0x7e57e014 MEMATTR=0x7cc3c018 Unaccepted=0x7c09e018
[0.00] efi: [Firmware
From: Ashish Kalra
The patchset adds bits and pieces to get kexec (and crashkernel) work on
SNP guest.
The series is based off of and tested against Kirill Shutemov's tree:
https://github.com/intel/tdx.git guest-kexec
v6:
- Updated and restructured the commit message for patch 1
From: Ashish Kalra
Handle cases where the RMP table placement in the BIOS is
not 2M aligned and then the kexec kernel could try to allocate
from within that chunk and that causes a fatal RMP fault.
The kexec failure is illustrated below from the kernel logs:
[0.00] SEV-SNP: RMP table
From: Ashish Kalra
Export a new API helper function e820__range_update_table() to update both
e820_table_kexec and e820_table_firmware. Move all current users of
e820__range_update_kexec() to use this new helper function.
Signed-off-by: Ashish Kalra
---
arch/x86/include/asm/e820/api.h | 2
From: Ashish Kalra
Handle cases where the RMP table placement in the BIOS is
not 2M aligned and then the kexec kernel could try to allocate
from within that chunk and that causes a fatal RMP fault.
Check if RMP table start & end physical range in e820 tables
are not aligned to 2MB and in
From: Ashish Kalra
SNP guests allocate shared buffers to perform I/O. It is done by
allocating pages normally from the buddy allocator and converting them
to shared with set_memory_decrypted().
The second kernel has no idea what memory is converted this way. It only
sees E820_TYPE_RAM
From: Ashish Kalra
Accessing guest video memory/RAM during kernel decompressor
causes guest termination as boot stage2 #VC handler for
SEV-ES/SNP systems does not support MMIO handling.
This issue is observed with SEV-ES/SNP guest kexec as
kexec -c adds screen_info to the boot parameters
passed
From: Ashish Kalra
For kexec use case, need to use and stick to the EFI memmap passed
from the first kernel via boot-params/setup data, hence,
skip efi_arch_mem_reserve() during kexec.
Additionally during SNP guest kexec testing discovered that EFI memmap
is corrupted during chained kexec
From: Ashish Kalra
The patchset adds bits and pieces to get kexec (and crashkernel) work on
SNP guest.
The series is based off of and tested against Kirill Shutemov's tree:
https://github.com/intel/tdx.git guest-kexec
v5:
- Removed sev_es_enabled() function and using sev_s
From: Ashish Kalra
SNP guests allocate shared buffers to perform I/O. It is done by
allocating pages normally from the buddy allocator and converting them
to shared with set_memory_decrypted().
The second kernel has no idea what memory is converted this way. It only
sees E820_TYPE_RAM
From: Ashish Kalra
For kexec use case, need to use and stick to the EFI memmap passed
from the first kernel via boot-params/setup data, hence,
skip efi_arch_mem_reserve() during kexec.
Additionally during SNP guest kexec testing discovered that EFI memmap
is corrupted during chained kexec
From: Ashish Kalra
Accessing guest video memory/RAM during kernel decompressor
causes guest termination as boot stage2 #VC handler for
SEV-ES/SNP systems does not support MMIO handling.
This issue is observed with SEV-ES/SNP guest kexec as
kexec -c adds screen_info to the boot parameters
passed
From: Ashish Kalra
Add sev_es_enabled() function to detect if SEV-ES
support is enabled.
Signed-off-by: Ashish Kalra
Reviewed-by: Kuppuswamy Sathyanarayanan
---
arch/x86/boot/compressed/sev.c | 5 +
arch/x86/boot/compressed/sev.h | 2 ++
2 files changed, 7 insertions(+)
diff --git a
From: Ashish Kalra
The patchset adds bits and pieces to get kexec (and crashkernel) work on
SNP guest.
v4:
- Rebased to current tip/master.
- Reviewed-bys from Sathya.
- Remove snp_kexec_unprep_rom_memory() as it is not needed any more as
SEV-SNP code is not validating the ROM range in
From: Ashish Kalra
SNP guests allocate shared buffers to perform I/O. It is done by
allocating pages normally from the buddy allocator and converting them
to shared with set_memory_decrypted().
The second kernel has no idea what memory is converted this way. It only
sees E820_TYPE_RAM
From: Ashish Kalra
Accessing guest video memory/RAM during kernel decompressor
causes guest termination as boot stage2 #VC handler for
SEV-ES/SNP systems does not support MMIO handling.
This issue is observed with SEV-ES/SNP guest kexec as
kexec -c adds screen_info to the boot parameters
passed
From: Ashish Kalra
Add sev_es_enabled() function to detect if SEV-ES
support is enabled.
Signed-off-by: Ashish Kalra
---
arch/x86/boot/compressed/sev.c | 5 +
arch/x86/boot/compressed/sev.h | 2 ++
2 files changed, 7 insertions(+)
diff --git a/arch/x86/boot/compressed/sev.c b/arch/x86
From: Ashish Kalra
For kexec use case, need to use and stick to the EFI memmap passed
from the first kernel via boot-params/setup data, hence,
skip efi_arch_mem_reserve() during kexec.
Additionally during SNP guest kexec testing discovered that EFI memmap
is corrupted during chained kexec
From: Ashish Kalra
The patchset adds bits and pieces to get kexec (and crashkernel) work on
SNP guest.
v3:
- Rebased;
- moved Keep page tables that maps E820_TYPE_ACPI patch to Kirill's tdx
guest kexec patch series.
- checking the md attribute instead of checking the efi_setup for
dete
From: Ashish Kalra
SNP guests allocate shared buffers to perform I/O. It is done by
allocating pages normally from the buddy allocator and converting them
to shared with set_memory_decrypted().
The second kernel has no idea what memory is converted this way. It only
sees E820_TYPE_RAM
From: Ashish Kalra
During crashkernel boot only pre-allocated crash memory is presented as
E820_TYPE_RAM. This can cause page table entries mapping unaccepted memory
table to be zapped during phys_pte_init(), phys_pmd_init(), phys_pud_init()
and phys_p4d_init() as SNP/TDX guest use
From: Ashish Kalra
For kexec use case, need to use and stick to the EFI memmap passed
from the first kernel via boot-params/setup data, hence,
skip efi_arch_mem_reserve() during kexec.
Additionally during SNP guest kexec testing discovered that EFI memmap
is corrupted during chained kexec
From: Ashish Kalra
The patchset adds bits and pieces to get kexec (and crashkernel) work on
SNP guest.
v2:
- address zeroing of unaccepted memory table mappings at all page table levels
adding phys_pte_init(), phys_pud_init() and phys_p4d_init().
- include skip efi_arch_mem_reserve() in case
From: Ashish Kalra
SNP guests allocate shared buffers to perform I/O. It is done by
allocating pages normally from the buddy allocator and converting them
to shared with set_memory_decrypted().
The second kernel has no idea what memory is converted this way. It only
sees E820_TYPE_RAM
From: Ashish Kalra
The patchset adds bits and pieces to get kexec (and crashkernel) work on
SNP guest.
This patchset requires [1] for chained guest kexec to work correctly.
[1]: https://lore.kernel.org/lkml/20240219225451.787816-1-ashish.ka...@amd.com/
Ashish Kalra (2):
x86/mm: Do not zap
From: Ashish Kalra
During crashkernel boot only pre-allocated crash memory is presented as
E820_TYPE_RAM. This can cause PMD entry mapping unaccepted memory table
to be zapped during phys_pmd_init() as SNP/TDX guest use E820_TYPE_ACPI
to store the unaccepted memory table and pass it between the
From: Ashish Kalra
For kexec use case, need to use and stick to the EFI memmap passed
from the first kernel via boot-params/setup data, hence,
skip efi_arch_mem_reserve() during kexec.
Additionally during SNP guest kexec testing discovered that EFI memmap
is corrupted during chained kexec
From: Ashish Kalra
For kexec use case, need to use and stick to the EFI memmap passed
from the first kernel via boot-params/setup data, hence,
skip efi_arch_mem_reserve() during kexec.
Additionally during SNP guest kexec testing discovered that EFI memmap
is corrupted during chained kexec
From: Ashish Kalra
Reset the host's shared pages list related to kernel
specific page encryption status settings before we load a
new kernel by kexec. We cannot reset the complete
shared pages list here as we need to retain the
UEFI/OVMF firmware specific settings.
The host's shared
MSR_KVM_MIGRATION_CONTROL to enable SEV
live migration ?
Thanks,
Ashish
On Wed, Apr 21, 2021 at 06:48:32PM +, Ashish Kalra wrote:
> Hello Paolo,
>
> The earlier patch#10 of SEV live migration patches which is now part of
> the guest interface patches us
wrote:
> On 21/04/21 16:44, Borislav Petkov wrote:
> > On Thu, Apr 15, 2021 at 04:01:16PM +0000, Ashish Kalra wrote:
> > > From: Ashish Kalra
> > >
> > > The guest support for detecting and enabling SEV Live migration
> > > feature uses the follow
On Wed, Apr 21, 2021 at 04:44:02PM +0200, Borislav Petkov wrote:
> On Thu, Apr 15, 2021 at 04:01:16PM +0000, Ashish Kalra wrote:
> > From: Ashish Kalra
> >
> > The guest support for detecting and enabling SEV Live migration
> > feature uses the following logic :
&
From: Ashish Kalra
The guest support for detecting and enabling SEV Live migration
feature uses the following logic :
- kvm_init_plaform() invokes check_kvm_sev_migration() which
checks if its booted under the EFI
- If not EFI,
i) check for the KVM_FEATURE_CPUID
ii) if CPUID
On Mon, Apr 12, 2021 at 07:25:03PM -0700, Steve Rutherford wrote:
> On Mon, Apr 12, 2021 at 6:48 PM Ashish Kalra wrote:
> >
> > On Mon, Apr 12, 2021 at 06:23:32PM -0700, Steve Rutherford wrote:
> > > On Mon, Apr 12, 2021 at 5:22 PM Steve Rutherford
> > > wrot
On Mon, Apr 12, 2021 at 06:23:32PM -0700, Steve Rutherford wrote:
> On Mon, Apr 12, 2021 at 5:22 PM Steve Rutherford
> wrote:
> >
> > On Mon, Apr 12, 2021 at 12:48 PM Ashish Kalra wrote:
> > >
> > > From: Ashish Kalra
> > >
> > >
From: Ashish Kalra
Reset the host's shared pages list related to kernel
specific page encryption status settings before we load a
new kernel by kexec. We cannot reset the complete
shared pages list here as we need to retain the
UEFI/OVMF firmware specific settings.
The host's shared
From: Ashish Kalra
Reset the host's shared pages list related to kernel
specific page encryption status settings before we load a
new kernel by kexec. We cannot reset the complete
shared pages list here as we need to retain the
UEFI/OVMF firmware specific settings.
The host's shared
From: Ashish Kalra
Reset the host's page encryption bitmap related to kernel
specific page encryption status settings before we load a
new kernel by kexec. We cannot reset the complete
page encryption bitmap here as we need to retain the
UEFI/OVMF firmware specific settings.
The host&#
From: Ashish Kalra
Reset the host's page encryption bitmap related to kernel
specific page encryption status settings before we load a
new kernel by kexec. We cannot reset the complete
page encryption bitmap here as we need to retain the
UEFI/OVMF firmware specific settings.
Signed-o
83 matches
Mail list logo
