On 26.07.21 21:02, Joerg Roedel wrote:
On Thu, Jul 22, 2021 at 05:46:13PM +0200, David Hildenbrand wrote:
+1, this smells like an anti-patter. I'm absolutely not in favor of a
bitmap, we have the sparse memory model for a reason.
Well, I doubt that TDX or SNP guests will be set up with a sparse memory
layout.
What makes you think that? I already heard people express desires for
memory hot(un)plug, especially in the context of running containers
inside encrypted VMs. And static bitmaps are naturally a bad choice for
changing memory layouts.
Also, I am not convinced that kexec/kdump is actually easy to realize with
the bitmap?
Who will forward that bitmap?
The kernel decompressor will create it and forward it to the
decompressed kernel image. The running kernel will pass it on to
kexec'ed kernels for the lifetime of the system.
How will the second kernel figure out the location? Similar to how we
pass the physical address of the vmcore header via the cmdline to the
new kernel?
Where will it reside?
In Linux kernel owned memory, location decided by the kernel
decompressor.
Okay, owned by the old kernel, not initially mapped by new kernel in the
identity mapping. Is there a prototype/code that implements that?
Who says it's not corrupted?
If the hypervisor corrupts it we can notice it. The guest kernel can
corrupt it on its own, but that is true for all data in the guest, also
the memmap.
Yes, but it does not affect the kdump kernel booting, only makedumpfile
might bail out later when it detects a corruption.
I'm wondering, why exactly would a kdump kernel (not touching memory of
the old kernel while booting up) need access to the bitmap? Just
wondering, for ACPI tables and such? I can understand why makedumpfile
would need that information when actually dumping memory of the old
kernel, but it would have access to the memmap of the old kernel to
obtain that information.
Just take a look at how we don't even have access to memmap of the
oldkernel in the newkernel -- and have to locate and decipher it in
constantly-to-be-updated user space makedumpfile. Any time you'd
change anything about the bitmap ("hey, let's use larger chunks",
"hey, let's split it up") you'd break the old_kernel
<-> new_kernel agreement.
Im not sure if makedumpfile needs to know about that bitmap. If we
mirror the same information into the memmap, then there is definitly no
need for it.
Mirroring is a good point. But I'd suggest using the bitmap only during
early boot if really necessary and after syncing it to the bitmap, get
rid of it. Sure, kexec is more challenging, but at least it's a clean
design. We can always try expressing the state of validated memory in
the e820 map we present to the kexec kernel.
--
Thanks,
David / dhildenb
