Re: [BUGFIX] [PATCH] kexec/x86: Do map crash kernel area

[Daniel Kiper <daniel.kiper@oracle.com>]

On Wed, Jan 01, 2014 at 05:47:16PM +0000, Andrew Cooper wrote:
> On 01/01/2014 16:51, Don Slutz wrote:

[...]

> > With this patch no panic and crash kernel works.
> >
> > Signed-off-by: Don Slutz <dslutz@verizon.com>
>
> Commit 7113a45451a9f656deeff070e47672043ed83664 was clearly not tested.
> kimage_alloc_crash_control_page() explicitly chooses a page inside the
> crash region and clears it.

I tested this patch earlier and now with latest Xen and kexec-tools commits.
I am not able to reproduce this issue on my machines. Don, could you
provide more details about your system and how did you build your
Xen and kexec-tools (configure, make options, etc.)?

Andrew, David, Did you run kexec tests in your automated test environment
with commit 7113a45451a9f656deeff070e47672043ed83664 applied? Could you
tell something about results?

> However, the sentiment of the commit is certainly desirable, to prevent
> accidental playing in the crash region.
>
> As the mappings are removed from Xen's directmap region,
> map_domain_page() doesn't work (unless the debug highmem barrier is
> sufficiently low that the crash regions ends up above it, and the
> virtual address ends up coming from the mapcache).
>
> This means that both here in clear_domain_page(), and later in
> machine_kexec_load() where the code is copied in, is vulnerable to this
> pagefault.
>
> The solution to this problem which would leave the fewest mappings would
> be to have kimage_alloc_crash_control_page() map the individual control
> page to the main Xen pagetables, at which a call to point
> map_domain_page() on it will work correctly.  This would need an
> equivalent call to destroy_xen_mappings() in kimage_free().
>
> However, it is far from neat.
>
> I defer to others as to which approach is better, but suggest that one
> way or another, the problem gets fixed very quickly, even if that means
> taking this complete reversion now and submitting a proper fix in due
> course.

I am on holiday until 06th January 2014 and I am not able to investigate
this issue deeper right now. If you feel that it is better to revert
this patch and later do second attempt to remove this mapping I do
not object.

Daniel