On 09/30/19 at 05:14am, Eric W. Biederman wrote: > Baoquan He <bhe@xxxxxxxxxx> writes: > >> needs a little better description. I know it is not a lot on modern > >> systems but reserving an extra 1M of memory to avoid having to special > >> case it later seems in need of calling out. > >> > >> I have an old system around that I think that 640K is about 25% of > >> memory. > > > > Understood. Basically 640K is wasted in this case. But we only do like > > this in SME case, a condition checking is added. And system with SME is > > pretty new model, it may not impact the old system. > > The conditional really should be based on if we are reserving memory > for a kdump kernel. AKA if crash_kernel=XXX is specified on the kernel > command line. > > At which point I think it would be very reasonable to unconditionally > reserve the low 640k, and make the whole thing a non-issue. This would > allow the kdump code to just not do anything special for any of the > weird special case. > > It isn't perfect because we need a page or so used in the first kernel > for bootstrapping the secondary cpus, but that seems like the least of > evils. Especially as no one will DMA to that memory. > > So please let's just change what memory we reserve when crash_kernel is > specified. Yes, makes sense, thanks for pointing it out. > > >> How we interact with BIOS tables in the first 640k needs some > >> explanation. Both in the first kernel and in the crash kernel. > > > > Yes, totally agree. > > > > Those BIOS tables have been reserved as e820 reserved regions and will > > be passed to kdump kernel for reusing. Memblock reserved 640K doesn't > > mean it will cover the whole [0, 640K) region, it only searches for > > available system RAM from memblock allocator. > > Careful with that assumption. My memory is that the e820 memory map > frequently fails to cover areas like the real mode interrupt descriptor > table at address 0. OK, will think more about this. Thanks. _______________________________________________ kexec mailing list kexec@xxxxxxxxxxxxxxxxxxx http://lists.infradead.org/mailman/listinfo/kexec