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...
Thanks,
Tao Liu
--
Best regards,
Coiby
_______________________________________________
kexec mailing list -- kexec(a)lists.fedoraproject.org
To unsubscribe send an email to kexec-leave(a)lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines:
https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/kexec@lists.fedoraproject.org
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue