Hi Tao,
On Sat, Apr 02, 2022 at 02:14:38PM +0800, Tao Liu wrote:
Hi Philipp,
On Wed, Mar 30, 2022 at 11:34 PM Philipp Rudo prudo@redhat.com wrote:
[...]
implemented the reservation in the kernel side, as part of the kernel crashkernel=auto implementation.
For swiotlb, I think Dave and Emma prefer to do it in kernel space. Maybe you can try a kernel space solution first like [1]?
[1] https://lore.kernel.org/lkml/20190910151341.14986-3-kasong@redhat.com/
For rhel9 however, crashkernel=auto has been mirrored to userspace kexec-tools, so this patch will enable the swiotlb reservation for AMD sme/sev in kexec-tools as well.
Not really about this patch but I find it weird that we adjust the crashkernel=auto value for swiotlb but not for other cases wher we know that we need a larger crashkernel, e.g. when the dump target is on a LUKS encrypted device. I understand that in the past, when crashkernel=auto was handled by the kernel, we simply didn't know about what the dump target will be when we allocated the crashkernel during boot. But today, when crashkernel=auto is handled in userspace we can.
I didn't have much context on LUKS, by looking into the code, I see only "kdumpctl estimate" has the LUKS related crashkernel value increment. It needs the user to adjust crashkernel value manually by estimate-and-set. Maybe we can merge the crashkernel adjustment of swiotlb and luks together, so luks don't need to "kdumpctl estimate" manually anymore?
For LUKS, a kernel-space solution by reusing LUKS master key is preferred because a) LUKS requires too much memory b) we can't expect the user to wait at the screen to input the passphrase to open the disk when kernel crashes. Let's see how far my work [2] can go.
[2] https://lore.kernel.org/lkml/20220321014150.w6wux5azabweu7dr@Rk/T/