Hi Dave,
On 9/14/2024 6:08 AM, Dave Young wrote:
> Hi Ashish,
>
> I'm reading the code about E820 tables related code, I noticed with
> below commit you updated all three e820 tabes including
> e820_table_kexec and e820_table_firmware.
> commit 400fea4b9651adf5d7ebd5d71e905f34f4e4e493
> Author: A
Hello Mike,
On 9/4/2024 2:54 PM, Michael Roth wrote:
> On Wed, Sep 04, 2024 at 12:37:17PM -0500, Kalra, Ashish wrote:
>> Hello Paolo,
>>
>> On 9/4/2024 5:29 AM, Paolo Bonzini wrote:
>>> On 9/4/24 00:58, Kalra, Ashish wrote:
>>>> The issue here is that pa
Hello Sean,
>>> e_free_context:
>>> @@ -2884,9 +2890,126 @@ static int snp_decommission_context(struct kvm *kvm)
>>> snp_free_firmware_page(sev->snp_context);
>>> sev->snp_context = NULL;
>>>
>>> + if (snp_asid_to_gctx_pages_map)
>>> + snp_asid_to_gctx_pages_map[sev_get_asid
Hello Paolo,
On 9/4/2024 5:29 AM, Paolo Bonzini wrote:
> On 9/4/24 00:58, Kalra, Ashish wrote:
>> The issue here is that panic path will ensure that all (other) CPUs
>> have been shutdown via NMI by checking that they have executed the
>> NMI shutdown callback.
>>
>&
Hello Sean,
On 9/3/2024 2:52 PM, Sean Christopherson wrote:
> On Tue, Sep 03, 2024, Ashish Kalra wrote:
>> From: Ashish Kalra
>> [1.671804] AMD-Vi: Using global IVHD EFR:0x841f77e022094ace, EFR2:0x0
>> [1.679835] AMD-Vi: Translation is already enabled - trying to copy
>> translation stru
Hello Boris,
On 8/29/2024 10:16 AM, Kalra, Ashish wrote:
> On 8/29/2024 9:50 AM, Sean Christopherson wrote:
>
>> On Thu, Aug 29, 2024, Borislav Petkov wrote:
>>> On August 27, 2024 10:38:04 PM GMT+02:00, Ashish Kalra
>>> wrote:
>>>> From: A
On 8/29/2024 9:50 AM, Sean Christopherson wrote:
> On Thu, Aug 29, 2024, Borislav Petkov wrote:
>> On August 27, 2024 10:38:04 PM GMT+02:00, Ashish Kalra
>> wrote:
>>> From: Ashish Kalra
>>>
>>> With active SNP VMs, SNP_SHUTDOWN_EX invoked during panic notifiers causes
>>> crashkernel boot fail
Hello Boris,
On 8/29/2024 3:34 AM, Borislav Petkov wrote:
> On August 27, 2024 10:38:04 PM GMT+02:00, Ashish Kalra
> wrote:
>> From: Ashish Kalra
>>
>> With active SNP VMs, SNP_SHUTDOWN_EX invoked during panic notifiers causes
>> crashkernel boot failure with the following signature:
> Why woul
On 7/5/2024 9:29 AM, Borislav Petkov wrote:
> On Tue, Jul 02, 2024 at 07:58:11PM +, Ashish Kalra wrote:
>> +static bool make_pte_private(pte_t *pte, unsigned long addr, int pages, int
>> level)
>> +{
>> +struct sev_es_runtime_data *data;
>> +struct ghcb *ghcb;
>> +int cpu;
>> +
>>
On 6/24/2024 1:26 PM, Borislav Petkov wrote:
>> + */
>> +
>> +addr = PAGE_OFFSET;
>> +end = PAGE_OFFSET + get_max_mapped();
>> +
>> +while (addr < end) {
>> +unsigned long size;
>> +unsigned int level;
>> +pte_t *pte;
>> +
>> +pte =
Hello Tom,
On 6/28/2024 9:01 AM, Tom Lendacky wrote:
> On 6/27/24 23:27, Kalra, Ashish wrote:
>> Hello Boris,
>>
>> On 6/24/2024 10:59 PM, Borislav Petkov wrote:
>>> On Mon, Jun 24, 2024 at 03:57:34PM -0500, Kalra, Ashish wrote:
>>>> ... Hence, adde
Hello Boris,
On 6/24/2024 10:59 PM, Borislav Petkov wrote:
> On Mon, Jun 24, 2024 at 03:57:34PM -0500, Kalra, Ashish wrote:
>> ... Hence, added simple static functions make_pte_private() and
>> set_pte_enc() to make use of the more optimized snp_set_memory_private() to
>> us
On 6/24/2024 1:26 PM, Borislav Petkov wrote:
>> @@ -92,6 +94,9 @@ static struct ghcb *boot_ghcb __section(".data");
>> /* Bitmap of SEV features supported by the hypervisor */
>> static u64 sev_hv_features __ro_after_init;
>>
>> +/* Last address to be switched to private during kexec */
>> +st
On 6/4/2024 8:48 PM, Dave Young wrote:
> On Wed, 5 Jun 2024 at 06:36, Kalra, Ashish wrote:
>> Re-sending as the earlier response got line-wrapped.
>>
>> On 6/3/2024 12:12 PM, Borislav Petkov wrote:
>>> On Mon, Jun 03, 2024 at 12:08:48PM -0500, Kalra, Ashish wr
Hello Dave,
On 6/4/2024 8:58 PM, Dave Young wrote:
> On Wed, 5 Jun 2024 at 09:52, Dave Young wrote:
...
if (efi.memmap.flags & (EFI_MEMMAP_MEMBLOCK | EFI_MEMMAP_SLAB)) {
__efi_memmap_free(efi.memmap.phys_map,
efi.
Re-sending as the earlier response got line-wrapped.
On 6/3/2024 12:12 PM, Borislav Petkov wrote:
> On Mon, Jun 03, 2024 at 12:08:48PM -0500, Kalra, Ashish wrote:
>> efi_arch_mem_reserve().
> Now it only remains for you to explain why...
Here is a detailed explanation of what is cau
On 6/3/2024 12:12 PM, Borislav Petkov wrote:
> On Mon, Jun 03, 2024 at 12:08:48PM -0500, Kalra, Ashish wrote:
>> efi_arch_mem_reserve().
> Now it only remains for you to explain why...
Here is a detailed explanation of what is causing the EFI memory map
corruption, with added de
Re-sending this, last response got garbled.
On 6/3/2024 11:48 AM, Kalra, Ashish wrote:
On 6/3/2024 10:31 AM, Mike Rapoport wrote:
On Mon, Jun 03, 2024 at 04:46:39PM +0200, Borislav Petkov wrote:
On Mon, Jun 03, 2024 at 09:01:49AM -0500, Kalra, Ashish wrote:
If we skip efi_arch_mem_reserve
On 6/3/2024 11:57 AM, Borislav Petkov wrote:
On Mon, Jun 03, 2024 at 11:48:03AM -0500, Kalra, Ashish wrote:
Yes, something similar as above, as efi_mem_reserve() is used to reserve
boot service memory and is not necessary for kexec boot.
So, Dave Young (dyo...@redhat.com) had suggested that
On 6/3/2024 10:31 AM, Mike Rapoport wrote:
On Mon, Jun 03, 2024 at 04:46:39PM +0200, Borislav Petkov wrote:
On Mon, Jun 03, 2024 at 09:01:49AM -0500, Kalra, Ashish wrote:
If we skip efi_arch_mem_reserve() (which should probably be anyway skipped
for kexec case), then for kexec boot, EFI
On 6/3/2024 10:29 AM, Mike Rapoport wrote:
On Mon, Jun 03, 2024 at 09:01:49AM -0500, Kalra, Ashish wrote:
On 6/3/2024 8:39 AM, Mike Rapoport wrote:
On Mon, Jun 03, 2024 at 08:06:56AM -0500, Kalra, Ashish wrote:
On 6/3/2024 3:56 AM, Borislav Petkov wrote
EFI memory map and due to early
On 6/3/2024 8:39 AM, Mike Rapoport wrote:
On Mon, Jun 03, 2024 at 08:06:56AM -0500, Kalra, Ashish wrote:
On 6/3/2024 3:56 AM, Borislav Petkov wrote
EFI memory map and due to early allocation it uses memblock allocation.
Later during boot, efi_enter_virtual_mode() calls
On 6/3/2024 3:56 AM, Borislav Petkov wrote
EFI memory map and due to early allocation it uses memblock allocation.
Later during boot, efi_enter_virtual_mode() calls kexec_enter_virtual_mode()
in case of a kexec-ed kernel boot.
This function kexec_enter_virtual_mode() installs the new EFI memor
Hello Boris,
On 5/31/2024 10:14 AM, Borislav Petkov wrote:
static int __set_memory_enc_dec(unsigned long addr, int numpages, bool enc)
{
- if (cc_platform_has(CC_ATTR_MEM_ENCRYPT))
- return __set_memory_enc_pgtable(addr, numpages, enc);
+ int ret = 0;
- return 0;
On 5/9/2024 4:56 AM, Ruirui Yang wrote:
On Fri, Apr 26, 2024 at 04:33:48PM +, Ashish Kalra wrote:
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=
Hello Alexander,
On 5/2/2024 7:01 AM, Alexander Graf wrote:
Hey Ashish,
On 09.04.24 22:42, Ashish Kalra wrote:
From: Ashish Kalra
The patchset adds bits and pieces to get kexec (and crashkernel) work on
SNP guest.
With this patch set (and similar for the TDX one), you enable the
typical
On 4/26/2024 10:34 AM, Borislav Petkov wrote:
On Fri, Apr 26, 2024 at 10:28:41AM -0500, Kalra, Ashish wrote:
"Chained guest kexec" is when we are in a guest and kexec-ing into a new
kernel and then this kernel kexecs into another and so on ...
Make sure to explain your terminolo
On 4/26/2024 10:22 AM, Borislav Petkov wrote:
On Fri, Apr 26, 2024 at 09:47:02AM -0500, Kalra, Ashish wrote:
I should have mentioned *chained* guest kexec above instead of nested guest
kexec.
What is a "chained guest kexec" now?
"Chained guest kexec" is when we are in a
On 4/26/2024 9:21 AM, Borislav Petkov wrote:
On Wed, Apr 24, 2024 at 04:17:09PM -0500, Kalra, Ashish wrote:
With SNP guest kexec and during nested guest kexec, observe the following
efi memmap corruption :
Before we delve any deeper here, lemme make sure I understand this
correctly:
* You&#x
>It sounds to me like you need to go back up, to the 1ft view and
explain how exactly this efi_mem_reserve() causes trouble for the
kexec-ed kernel so that we can think of a proper solution, not some
random hackery.
The above details explain why and how efi_arch_mem_reserve() causes
troubl
Hello Boris,
On 4/24/2024 9:48 AM, Borislav Petkov wrote:
On Mon, Apr 15, 2024 at 11:22:58PM +, Ashish Kalra wrote:
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() du
Hi Kirill,
On 3/25/2024 5:38 AM, Kirill A. Shutemov wrote:
The patchset adds bits and pieces to get kexec (and crashkernel) work on
TDX guest.
The last patch implements CPU offlining according to the approved ACPI
spec change poposal[1]. It unlocks kexec with all CPUs visible in the target
kern
Hello,
On 3/18/2024 11:00 PM, Dave Young wrote:
Hi,
Added Ard in cc.
On 03/18/24 at 07:02am, Ashish Kalra wrote:
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
Hi Kirill,
On 2/20/2024 6:42 AM, Kirill A. Shutemov wrote:
On Tue, Feb 20, 2024 at 01:18:29AM +, Ashish Kalra wrote:
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 zap
Hello Kirill,
On 1/29/2024 4:36 AM, Kirill A. Shutemov wrote:
On Mon, Jan 29, 2024 at 04:24:09AM -0600, Kalra, Ashish wrote:
In case of SNP and crash/kdump case, we need to prevent the boot_ghcb being
converted to shared (in snp_kexec_unshare_mem()) as the boot_ghcb is
required to handle all I
Hello Kirill,
On 1/24/2024 6:55 AM, Kirill A. Shutemov wrote:
TDX 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 thi
On 10/6/2023 10:11 AM, Kirill A. Shutemov wrote:
On Fri, Oct 06, 2023 at 07:58:03AM -0700, Sean Christopherson wrote:
On Thu, Oct 05, 2023, Kirill A. Shutemov wrote:
diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index 7368d254d01f..b5acf9fb4c70 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/
On 10/5/2023 5:28 PM, Kirill A. Shutemov wrote:
On Thu, Oct 05, 2023 at 05:01:23PM -0500, Kalra, Ashish wrote:
On 10/5/2023 4:28 PM, Kirill A. Shutemov wrote:
On Thu, Oct 05, 2023 at 01:41:38PM -0500, Kalra, Ashish wrote:
+static void unshare_all_memory(bool unmap)
+{
+ unsigned long
On 10/5/2023 4:28 PM, Kirill A. Shutemov wrote:
On Thu, Oct 05, 2023 at 01:41:38PM -0500, Kalra, Ashish wrote:
+static void unshare_all_memory(bool unmap)
+{
+ unsigned long addr, end;
+ long found = 0, shared;
+
+ /*
+* Walk direct mapping and convert all shared
Hello Kirill,
On 10/5/2023 8:13 AM, Kirill A. Shutemov wrote:
TDX 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 target kernel has no idea what memory is converted thi
40 matches
Mail list logo
