Re: [Xen-devel] [PATCHv11 3/9] kexec: add infrastructure for handling kexec images

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 18.11.13 at 13:25, Daniel Kiper <daniel.kiper@xxxxxxxxxx> wrote:
> On Mon, Nov 18, 2013 at 11:34:56AM +0000, Jan Beulich wrote:
>> >>> On 18.11.13 at 12:04, David Vrabel <david.vrabel@xxxxxxxxxx> wrote:
>> > On 18/11/13 08:07, Jan Beulich wrote:
>> >>>>> On 15.11.13 at 19:31, David Vrabel <david.vrabel@xxxxxxxxxx> wrote:
>> >>> On 15/11/13 14:35, Jan Beulich wrote:
>> >>>> The new code, however, appears to make assumptions that
>> >>>> the memory used here is part of the range covered by the
>> >>>> frame table, and hence setup.c's determination of the base
>> >>>> address would need to be adjusted accordingly. (I realize
>> >>>> that this only matters on systems having more RAM than the
>> >>>> hypervisor can make use of.)
>> >>>
>> >>> The relocation code wrote the image into the crash region, not the
>> >>> kernel, but I take your point.
>> >>>
>> >>> Is this a real problem or just a theoretical one for now?
>> >>
>> >> Not sure what "theoretical" here means - I know of actual systems
>> >> (even if perhaps not commercially available yet) that would be
>> >> affected by this.
>> >
>> > The administrator has to configure the location of the crash region.
>>
>> All he needs to specify is the size; specifying the location is optional.
>>
>> >  I
>> > was asking if there are systems that configure the crash region such
>> > that it would would end in the wrong place.
>> >
>> > It does appear that the simplest crashkernel configuration would get it
>> > wrong.  e.g., crashkernel=0-:64M
>>
>> Which you seem to confirm here.
> 
> Even if that this does not make sens mapping should work without any issue.
> We are mapping only one page at a time. So what is the limit in that case?

The issue is not a limit on mappable pages, but the fact that there's
potentially no struct page_info for some or all of the crash area.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel