On 08/30/23 at 04:05pm, Philipp Rudo wrote:
Hi Baoquan,
On Thu, 17 Aug 2023 22:53:57 +0800
Baoquan He <bhe(a)redhat.com> wrote:
> It's reported that kdump kernel failed to boot and can't dump vmcore
> when crashkernel=192M and SME/SEV is active.
>
> This is because swiotlb will be enabled and reserves 64M memory by
> default on system with SME/SEV enabled. Then kdump kernel will be out of
> memory after taking 64M away for swiotlb init.
>
> So here add extra 64M memory to default crashkernel value so that kdump
> kernel can function well as before. When doing that, search journalctl
> for the "Memory Encryption Features active: AMD" to check if SME or SEV
> is active. This line of log is printed out in kernel function as below
> and the type SME is mutual exclusive with type SEV.
> ***:
> arch/x86/mm/mem_encrypt.c:print_mem_encrypt_feature_info()
>
> Note:
> 1) The conditional check is relying on journalctl log because I didn't
> find available system interface to check if SEV is active. Even
> though we can check if SME is active via /proc/cpuinfo. For
> consistency, I take the same check for both SME and SEV by searching
> journalctl.
>
> 2) The conditional check is relying on journalctl log, means it won't
> work for crashkernel setting in anoconda because the installation
> kernel doesn't have the SME/SEV setting. So customer need manually
> run 'kdumpctl reset-crashkernel' to reset crashkernel to add the
> extra 64M after OS installation.
>
> 3) We need watch the line of log printing in
> print_mem_encrypt_feature_info() in kernel just in case people may
> change it in the future.
Thanks for careful checking, Phlipp.
Those are quite some heavy restrictions. I would like to find a
Hmm, Notes I given out are not heavy restrictions, they are notice and
explanation about more details.
Note 1) is why I take the way to do it.
3) is a reminder, as we know, kernel printing can't be changed casually
because user space utility will check them. This is what we often meet
and need to pay attention to when change kernel code.
Note 2) could be a shortage. I talked to Dave, it's acceptable. SME/SEV
operator need to some manual operation after OS installation on SME/SEV
platform.
solution that does not rely on checking journalctl. How about
instead
of checking if SME/SEV is enabled to check how much memory the swiotlb
has allocated. IIUC this is provided in
/sys/kernel/debug/swiotlb/io_tlb_used. With that the code should also
work for s390 (which also uses swiotlb in their SEV equivalent) as well
as makes it more future prove when the swiotlb might be allocated
dynamically [1].
Hmm, people could specify swiotlb= in kernel cmdline, we have filter
that out in kdump because kdump usually don't need swiotlb. Except of
SME/SEV which implicitly requires that.
Dynamic swiotlb saving memory takes effect mainly on embedded system. On
server, it could save memory at early stage of bootup, but finally still
need enough memory. Even though dynamic swiotlb is taken, we should
prepare sufficient memory for the whole life of kdump kernel. So, here
specifying a fixed value which is big enough to satisy swiotlb in all
cases is necessary. Imagine what early kdump could encounter.