Re: [Xen-devel] Backport request

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 13.01.14 at 12:30, David Vrabel <david.vrabel@xxxxxxxxxx> wrote:
> On 13/01/14 11:13, Jan Beulich wrote:
>>>>> On 13.01.14 at 10:49, Andrew Cooper <andrew.cooper3@xxxxxxxxxx> wrote:
>>> Can you please backport c/s 0896bd8bea84526b00e00d2d076f4f953a3d73cb
>>> "x86: map portion of kexec crash area that is within the direct map
>>> area" to staging-4.3 ASAP, as following the backport of
>>> 8d611a00d3389d9c16506326e24145b94ac6fb86 "kexec/x86: do not map crash
>>> kernel area", kexec loading is broken in exactly the same way as it was
>>> in staging.
>> 
>> Not without explaining how it is broken: According to my own
>> checking as well as Daniel's there was no need for the kexec area
>> to be mapped at all in the old implementation.
>> 
>> Furthermore, I'd prefer to revert 8d611a00 (dff90d0c on 4.2)
>> instead if there really is an issue. That's largely because, as
>> noted in the extra comment I added to 0896bd8b, the change is
>> still incomplete (and hence not much better than the code with
>> Daniel's change reverted).
> 
> In that comment it says:
> 
>   "That's primarily because map_domain_page()
>    (needed when the area is outside the direct mapping range) may be
>    unusable when wanting to kexec due to a crash,"
> 
> But map_domain_page() is only used when loading the crash image, not
> during exec.

That's good to know, but I don't think it's a good idea either. Seeing
that map_domain_page() is being used in the code _at all_ may
make someone try to use it in a path that is used during kexec. And
it being used by other functions in the same file may also result in
one of those functions suddenly also getting used on a kexec path.

Together with the issue of the area potentially ending up in a
PFN compression hole, to me this is enough reason to still expect
that these uses get dropped again.

Jan


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