Kexec Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: "Kalra, Ashish" <ashish.kalra@amd.com>
To: Dave Young <dyoung@redhat.com>
Cc: x86@kernel.org, linux-kernel@vger.kernel.org, kexec@lists.infradead.org
Subject: Re: question about RMP table fixups for kexec
Date: Mon, 16 Sep 2024 13:39:07 -0500	[thread overview]
Message-ID: <8170fb75-821d-46fb-80e4-c7bd5635d65c@amd.com> (raw)
In-Reply-To: <CALu+AoTKBRGgZW6JK19AV6QRTi7_eCzJbh9JCKENxsL7t061rQ@mail.gmail.com>

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: Ashish Kalra <ashish.kalra@amd.com>
> Date:   Fri Apr 26 00:43:18 2024 +0000
>
>     x86/sev: Add callback to apply RMP table fixups for kexec
>
> ...
>
> +       if (e820__mapped_any(pa, pa + PMD_SIZE, E820_TYPE_RAM)) {
> +               pr_info("Reserving start/end of RMP table on a 2MB
> boundary [0x%016llx]\n", pa);
> +               e820__range_update(pa, PMD_SIZE, E820_TYPE_RAM,
> E820_TYPE_RESERVED);
> +               e820__range_update_table(e820_table_kexec, pa,
> PMD_SIZE, E820_TYPE_RAM, E820_TYPE_RESERVED);
> +               e820__range_update_table(e820_table_firmware, pa,
> PMD_SIZE, E820_TYPE_RAM, E820_TYPE_RESERVED);
> +       }
> +}
>
> A question here is, have you tried only updating e820_table and
> e820_table_firmware?
>
> I do not know much about SEV,  if you update e820_table, then the
> memory range will be reserved in resouces, and kexec will not load
> segments into the reserved ranges,  during the 2nd kernel bootup  your
> code will be run again so I assume it is not necessary to pre-reserve
> in e820_table_kexec and passing to 2nd kernel.
>
> Could you confirm this question?

Yes, that is true but e820_table_kexec is passed on to the incoming kexec kernel as part of the boot params, so that will be the initial e820 memory map for the incoming kernel and to be safe we also modify the e820_table_kexec.

We have already observed memblock allocating memory from the initial e820 map before the above fixups modifies e820 tables for the 1st kernel and then this memblock memory getting allocated to guest and causing RMPUPDATE issues, as from the issue reported and fixed below:

[PATCH] x86/sev: ensure that RMP table fixups are reserved for memblock - Ashish Kalra (kernel.org) <https://lore.kernel.org/lkml/20240815221630.131133-1-Ashish.Kalra@amd.com/>

Therefore, it should be safer to have the initial e820 memory map being passed to the incoming/2nd kernel already have the fixups in it.

Thanks, Ashish


_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

      reply	other threads:[~2024-09-16 18:39 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-09-14 11:08 question about RMP table fixups for kexec Dave Young
2024-09-16 18:39 ` Kalra, Ashish [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=8170fb75-821d-46fb-80e4-c7bd5635d65c@amd.com \
    --to=ashish.kalra@amd.com \
    --cc=dyoung@redhat.com \
    --cc=kexec@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=x86@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox