[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [BUGFIX] [PATCH] kexec/x86: Do map crash kernel area
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@xxxxxxxxxxx> > > 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 _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |