On 09/01/23 at 01:46pm, Coiby Xu wrote:
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
Thanks for suggestion, Coiby.
I am fine with this. Just user trusts us that we have optimized default
crashkernel value with best effort. If we accept adding extra 64M whenever
mem_encrypt=on is added, we can accept adding extra 64M memory alway.
The thing is it may not be a optimization with best effort. My personal
thinking.
bug about this sme/sev feature when they find mem_encrypt=on
doesn't
enable sme/sev.