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

[Don Slutz <dslutz@xxxxxxxxxxx>]

On 01/01/14 20:41, Daniel Kiper wrote:
> 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.)?
It is an older fedora17 system.

dcs-xen-54:~/xen>cat /etc/default/grub
GRUB_TIMEOUT=15
GRUB_DISTRIBUTOR="Fedora"
GRUB_DEFAULT=2
GRUB_TERMINAL="serial"
GRUB_SERIAL_COMMAND="serial --unit=0 --speed=9600"
GRUB_CMDLINE_LINUX="rd.md=0 rd.dm=0 rd.lvm.lv=vg_f17-xen/lv_swap 
KEYTABLE=us SYSFONT=True rd.luks=0 console=ttyS0,9600n8 
rd.lvm.lv=vg_f17-xen/lv_root LANG=en_US.UTF-8 earlyprintk=ttyS0 
rd_NO_PLYMOUTH"
#GRUB_THEME="/boot/grub2/themes/system/theme.txt"
GRUB_CMDLINE_XEN="dom0_mem=2G loglvl=all guest_loglvl=all 
console_timestamps=1 com1=9600,8n1 console=com1 apic_verbosity=verbose 
crashkernel=256M@256M"
GRUB_CMDLINE_LINUX_XEN_REPLACE="rd.md=0 rd.dm=0 
rd.lvm.lv=vg_f17-xen/lv_swap  KEYTABLE=us SYSFONT=True rd.luks=0 
console=hvc0,9600n8 rd.lvm.lv=vg_f17-xen/lv_root LANG=en_US.UTF-8 
earlyprintk=xen rd_NO_PLYMOUTH"
dcs-xen-54:~/xen>cat .config
CONFIG_QEMU = http://xenbits.xen.org/git-http/qemu-xen-unstable.git
QEMU_UPSTREAM_EXTRA_CONFIG = --with-pkgversion=qemu-xen-4.4.0-rc1-0-gb97307e
QEMU_UPSTREAM_REVISION = qemu-xen-4.4.0-rc1
QEMU_UPSTREAM_URL = git@xxxxxxxxxxxxxxxxxxxxx:qemu.git
SEABIOS_UPSTREAM_TAG = rel-1.7.3.1
SEABIOS_UPSTREAM_URL = git@xxxxxxxxxxxxxxxxxxxxx:seabios-george.git
debug = n

dcs-xen-54:~/xen>uname -a
Linux dcs-xen-54 3.8.11-100.fc17.x86_64 #1 SMP Wed May 1 19:31:26 UTC 
2013 x86_64 x86_64 x86_64 GNU/Linux
Commands used to build (I use rpmbuild):

./configure --prefix=/usr --disable-stubdom
make dist
make -C xen MAP

The last is part of enabling xen crashdump analyser see:

http://lists.xen.org/archives/html/xen-devel/2013-02/msg01606.html

as are the patches:

* 588e9ba Adjust xen-crashdump-analyser info for 4.4.0
* f53550b Add new xen-crashdump-analyser info.
* a1f92d3 Introduce more offsets, and embed all offsets into the symbol file

Attached are these patches including the patch I use to enable rpmbuild 
(dcs-xen-54:~/xen>rpmbuild -bb xen-4.4.spec).  Not that I expect it to 
matter.  The "crashkernel=256M@256M" may be the key to reproducing it.
Also attached the complete console output from my test (kexec-broken.txt).

   -Don Slutz
> 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

Attachment: 0001-Adjust-to-use-rpmbuild.patch
Description: Text Data

Attachment: 0002-Introduce-more-offsets-and-embed-all-offsets-into-th.patch
Description: Text Data

Attachment: 0003-Add-new-xen-crashdump-analyser-info.patch
Description: Text Data

Attachment: 0004-Adjust-xen-crashdump-analyser-info-for-4.4.0.patch
Description: Text Data

Attachment: kexec-broken.txt
Description: Text document

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