On Fri, Sep 01, 2023 at 09:02:29AM +0800, Baoquan He wrote:
On 08/31/23 at 03:39pm, Coiby Xu 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.
We can't check them by detecting "mem_encrypt=on" because we can specify
'mem_encrypt=on' on any machine, amd system w/o sme/sev capability,
even on intel system. Even a amd system w/ sme capability, we can
disable it in register.
Thanks for the explanation! I could understand mem_encrypt=on doesn't
guarantee sme/sev is enabled. But if it's the only way for users to
enable sme/sev, personally I would prefer to detecting mem_encrypt=on to
improve usability by avoiding rebooting the system one more time. And I
don't think users will file a bug against kexec-tools when an extra 64M
is reserved when sme/sev isn't truly enabled. Instead users will file a
bug about this sme/sev feature when they find mem_encrypt=on doesn't
enable sme/sev.
--
Best regards,
Coiby