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

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> 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:
>>>>>>> On 08.11.13 at 13:50, David Vrabel <david.vrabel@xxxxxxxxxx> wrote:
>>>>> Add the code needed to handle and load kexec images into Xen memory or
>>>>> into the crash region.  This is needed for the new KEXEC_CMD_load and
>>>>> KEXEC_CMD_unload hypercall sub-ops.
>>>>
>>>> I know it's late in the game, but just now I started getting the
>>>> impression that this introduced a new limitation that needs to
>>>> be taken into consideration elsewhere: With the old
>>>> implementation it was the kernel's responsibility to write to
>>>> the reserved space or, where Xen needed to touch the space,
>>>> it did so via fixmap entries. Hence there was no need for the
>>>> area to have corresponding struct page_info.
>>>>
>>>> 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.

>>> I don't think
>>> it's unreasonable to require the crash region to be within the frame table.
>> 
>> Right - as I assume you don't want to change all of your mapping
>> code, the only alternative is for the restriction to be enforced when
>> allocating the memory block.
> 
> The
> 
>    map_pages_to_xen((unsigned long)__va(kexec_crash_area.start),
>                      kexec_crash_area.start >> PAGE_SHIFT,
>                      PFN_UP(kexec_crash_area.size), PAGE_HYPERVISOR);
> 
> call in __start_xen() suggests that this isn't a new problem.

Oh, indeed. So I looked at all the (old) kexec code, not finding any
such implication, and completely overlooked that boot time thing
(which appears to be superfluous with both the old _and_ new
implementations).

Jan



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