Re: [RFC] arm64: extra entries in /proc/iomem for kexec

[James Morse <james.morse@arm.com>]

Hi Akashi,

On 27/03/18 11:16, AKASHI Takahiro wrote:
> On Tue, Mar 20, 2018 at 01:18:34AM +0530, Bhupesh Sharma wrote:
>> On 03/14/2018 01:59 PM, AKASHI Takahiro wrote:
>>> Currently, there is a inconsistent view between (A) and the mainline's:
>>> see (A-1) and (B-1). If this is really a matter, I can fix it.
>>> Kexec-tools can be easily modified to accept both formats, though.

Ooer, what needs changing in kexec-tools? What happens if someone doesn't update
userspace at the same time?

Is there a format which doesn't require a user-space change, (and shouldn't we
pick that one?)


>>> 2. How should we determine which regions be exported in /proc/iomem?
>>>
>>>  a. Trust all the memblock_reserve'd regions as my previous patch [3] does.
>>>
>>>     As I said, it's a kind of "overkill." Some of regions, say fdt, are
>>>     not required to be preserved across kexec.
>>
>>
>> I think we should preserve all the memblock_reserve'd regions. So +1 on this
>> approach from my side. I believe it might help avoid issues we have seen in
>> the past with 'kexec-tools' _incorrectly_ determining which regions to pick
>> from the '/proc/iomem'.
> 
> As I said in my reply to Ard's comment, I now know *overkill* is not a big
> issue and I will go for this approach.

/sys/kernel/debug/memblock/reserved has all kinds of weird stuff in it,
including some smaller-than-a-page reservations that appear to come from the
percpu allocator.

I agree it will make the implementation simpler, and reserving 'too much' isn't
an issue.


Thanks,

James

_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec