From: Ingo Molnar <mingo@kernel.org>
To: Kairui Song <kasong@redhat.com>
Cc: linux-kernel@vger.kernel.org,
Thomas Gleixner <tglx@linutronix.de>,
Ingo Molnar <mingo@redhat.com>, Borislav Petkov <bp@alien8.de>,
Thomas Lendacky <Thomas.Lendacky@amd.com>,
Baoquan He <bhe@redhat.com>, Lianbo Jiang <lijiang@redhat.com>,
Dave Young <dyoung@redhat.com>,
x86@kernel.org,
"kexec@lists.infradead.org" <kexec@lists.infradead.org>
Subject: Re: [PATCH v3 2/2] x86/kdump: Reserve extra memory when SME or SEV is active
Date: Wed, 11 Sep 2019 07:56:18 +0200 [thread overview]
Message-ID: <20190911055618.GA104115@gmail.com> (raw)
In-Reply-To: <20190910151341.14986-3-kasong@redhat.com>
* Kairui Song <kasong@redhat.com> wrote:
> Since commit c7753208a94c ("x86, swiotlb: Add memory encryption support"),
> SWIOTLB will be enabled even if there is less than 4G of memory when SME
> is active, to support DMA of devices that not support address with the
> encrypt bit.
>
> And commit aba2d9a6385a ("iommu/amd: Do not disable SWIOTLB if SME is
> active") make the kernel keep SWIOTLB enabled even if there is an IOMMU.
>
> Then commit d7b417fa08d1 ("x86/mm: Add DMA support for SEV memory
> encryption") will always force SWIOTLB to be enabled when SEV is active
> in all cases.
>
> Now, when either SME or SEV is active, SWIOTLB will be force enabled,
> and this is also true for kdump kernel. As a result kdump kernel will
> run out of already scarce pre-reserved memory easily.
>
> So when SME/SEV is active, reserve extra memory for SWIOTLB to ensure
> kdump kernel have enough memory, except when "crashkernel=size[KMG],high"
> is specified or any offset is used. As for the high reservation case, an
> extra low memory region will always be reserved and that is enough for
> SWIOTLB. Else if the offset format is used, user should be fully aware
> of any possible kdump kernel memory requirement and have to organize the
> memory usage carefully.
>
> Signed-off-by: Kairui Song <kasong@redhat.com>
> ---
> arch/x86/kernel/setup.c | 20 +++++++++++++++++---
> 1 file changed, 17 insertions(+), 3 deletions(-)
>
> diff --git a/arch/x86/kernel/setup.c b/arch/x86/kernel/setup.c
> index 71f20bb18cb0..ee6a2f1e2226 100644
> --- a/arch/x86/kernel/setup.c
> +++ b/arch/x86/kernel/setup.c
> @@ -530,7 +530,7 @@ static int __init crashkernel_find_region(unsigned long long *crash_base,
> unsigned long long *crash_size,
> bool high)
> {
> - unsigned long long base, size;
> + unsigned long long base, size, mem_enc_req = 0;
>
> base = *crash_base;
> size = *crash_size;
> @@ -561,11 +561,25 @@ static int __init crashkernel_find_region(unsigned long long *crash_base,
> if (high)
> goto high_reserve;
>
> + /*
> + * When SME/SEV is active and not using high reserve,
> + * it will always required an extra SWIOTLB region.
> + */
> + if (mem_encrypt_active())
> + mem_enc_req = ALIGN(swiotlb_size_or_default(), SZ_1M);
> +
> base = memblock_find_in_range(CRASH_ALIGN,
> - CRASH_ADDR_LOW_MAX, size,
> + CRASH_ADDR_LOW_MAX,
> + size + mem_enc_req,
> CRASH_ALIGN);
What sizes are we talking about here?
- What is the possible size range of swiotlb_size_or_default()
- What is the size of CRASH_ADDR_LOW_MAX (the old limit)?
- Why do we replace one fixed limit with another fixed limit instead of
accurately sizing the area, with each required feature adding its own
requirement to the reservation size?
I.e. please engineer this into a proper solution instead of just
modifying it around the edges.
For example have you considered adding some sort of
kdump_memory_reserve(size) facility, which increases the reservation size
as something like SWIOTLB gets activated? That would avoid the ugly
mem_encrypt_active() flag, it would just automagically work.
Thanks,
Ingo
next prev parent reply other threads:[~2019-09-11 5:56 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-09-10 15:13 [PATCH v3 0/2] x86/kdump: Reserve extra memory when SME or SEV is active Kairui Song
2019-09-10 15:13 ` [PATCH v3 1/2] x86/kdump: Split some code out of reserve_crashkernel Kairui Song
2019-09-10 15:13 ` [PATCH v3 2/2] x86/kdump: Reserve extra memory when SME or SEV is active Kairui Song
2019-09-11 5:56 ` Ingo Molnar [this message]
[not found] ` <CACPcB9cEE5eYWixkUvMeLVdRC5qhrru9PbjbLLxP3k1jsbRanQ@mail.gmail.com>
2019-09-18 7:55 ` [PATCH v3 0/2] " Dave Young
2019-09-18 10:17 ` Kairui Song
2019-09-25 10:36 ` [PATCH v3 2/2] " Kairui Song
2019-09-27 5:42 ` Dave Young
2019-09-27 7:52 ` Kairui Song
2019-10-12 9:24 ` Kairui Song
2019-10-14 11:05 ` Dave Young
2019-10-14 11:11 ` Dave Young
2019-10-15 2:18 ` Dave Young
2019-10-15 17:18 ` Kairui Song
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=20190911055618.GA104115@gmail.com \
--to=mingo@kernel.org \
--cc=Thomas.Lendacky@amd.com \
--cc=bhe@redhat.com \
--cc=bp@alien8.de \
--cc=dyoung@redhat.com \
--cc=kasong@redhat.com \
--cc=kexec@lists.infradead.org \
--cc=lijiang@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=tglx@linutronix.de \
--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