On Thu, Aug 31, 2023 at 03:57:32PM +0800, Tao Liu wrote:
Hi Coiby,
On Thu, Aug 31, 2023 at 3:40 PM Coiby Xu <coxu(a)redhat.com> wrote:
>
> On Wed, Aug 30, 2023 at 04:05:54PM +0200, 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.
> >
> >Those are quite some heavy restrictions. I would like to find a
> >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].
>
> How do people work enable SME/SEV? If people enable it by adding the
> mem_encrypt=on kernel parameter, can we add the extra 64M by detecting
> this parameter? Since Anaconda supports adding extra kernel parameters,
> it will make setting crashkernel in Anconda work as well.
>
I guess checking mem_encrypt=on is not a good way. Because even if you
add "mem_encrypt=on" to kernel cmdline, you cannot verify if sev/sme
is successfully enabled or not. If sev/sme fails, we will reserve 64M
more memory for crashkernel, which is no harm, however I think the
check itself is not clean...
Anoter benefit of checking mem_encrypt=on is users could avoid rebooting
the system one more time. With current approach, users need to reboot
the system so mem_encrypt=on will take effect and reboot the system
againt for the crashkernel change to take info effect. I don't know how
often mem_encrypt=on will fail to enable SEV/SME but I think whoever
enales SME/SEV should confirm it has been truly enabled.
--
Best regards,
Coiby