On Tue, Jul 27, 2021 at 11:34:47AM +0200, David Hildenbrand wrote: > 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. In the worst case some memory in the bitmap is wasted when memory is hot-unplugged. The amount depends on how much memory one bit covers, but I don't see this as a show stopper. > 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? As I wrote in the initial proposal, the bitmap will be passed via boot_params. > Okay, owned by the old kernel, not initially mapped by new kernel in the > identity mapping. Is there a prototype/code that implements that? No, besides the prototype patch which Kirill sent around. > 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. The kdump kernel needs the bitmap to detect when the Hypervisor is doing something malicious, well, at least on its own memory. The kdump kernel has full access to the previous kernels memory and could also be tricked by the Hypervisor to reveal secrets. > 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. It depends on how fragmented the validated/unvalidated regions will get over time. I think currently it is not very fragmented, the biggest shared regions are the .bss_decrypted section and the DMA bounce buffer. But there are also a couple of page-size regions which need to be shared. For kexec these regions can be validated again when tearing down the APs, but for kdump it would be too fragile to do such extensive stuff before jumping the the kdump kernel. Regards, Joerg
