On 01/22/2013 10:23 AM, Thomas Renninger wrote: > This would be wrong. If kexec tries to declare usable memory via memmap= > which is set to reserved by the BIOS, a WARN_ON() or even better BUG_ON() > can/should be issued. This is then not possible anymore. You can't do that anyway, because memmap= is not kexec-specific. > Your suggestion would again make the e820 data useless. One would again > not know whether an area which is reserved really is meant for BIOS/HW > communication. And for example broken mmconf platforms for which > the check "is mmconf area is in reserved space" returns false, would now > try to setup mmconf in kdump case. Do you want to introduce another > e820 type: KDUMP_RESERVED which formerly was usable? This would preserve > e820 info, but I cannot see for what this should be good for. You just answered your own question. Yes, we already have such "kernel reserved" types, and we could make a "memmap reserved" >> Even more sense would be to pass the modified memmap to kexec... > Not sure what you mean with this. When kexec is called, you are in a > kernel which does not have a modified memmap. How can a modified map > get passed to kexec? The memory map is simply a data structure which is passed by kexec. It can be modified at will by the kexec tools. This is the Right Way to do any of this; using the command line is just a horribly fscked up hack in the first place. > Again: Please explain what is bad with this solution. > I cannot see a better and more robust way for kdump other than > reserving the original reserved memory areas as declared by the BIOS. It is bad because it creates more complexity than is needed. The whole point is that what we want is simply to switch type 1 to type X, with the sole exceptions being the areas explicitly reserved for the kdump kernel. -hpa
