Re: [Xen-devel] Using kexec-crashdump with recent Xen and Linux HVM

2015-03-11 Thread Vitaly Kuznetsov
Stefan Bader  writes:

> After being asked about this I started to play around with Xen-4.4.1/4.5
> together with HVM Linux guest running 3.13/3.16/3.19. With mixed success.
> Usually rather failing.
>
> From a bit of research most activity to enable things were back in 2011. There
> was a bit of a throwback around Linux 3.2[1] but it appears [2] restored this 
> in
> a backwards compatible way. Around 3.17 xen_nopv was introduced but I have not
> figured out a helpful usage of this.
>
> The failure exhibits no visible messages in the guest after the crash 
> stacktrace
> caused by sysreq-trigger while 1vcpu seems to be in a spinning loop. On the 
> host
> side I noticed changing messages (TX queue drain or EVCHNOP errors).
>
> Command-line is a mix of nomodeset (to keep cirrusdrm away) and some defaults
> from the kdump-tools (maxcpus=1 irqpoll nousb).
>
> The closest thing to success I can get to is using xen_emul_unplug=never for 
> the
> normal boot (which propagates into the kexec command). This of course stops
> usage of the pv drivers. I also tried some variation of blacklisting the
> emulated drivers and using xen_emul_unplug=unnecessary but that did not seem 
> to
> work for me. The crash-kexec boot without unplugging still fails to bring up 
> the
> NIC but at least finds the root disk to store the dump there. But not using 
> the
> pv drivers is not a setup one would want to have running just in case.
>
> So I was wondering whether I still miss something.

No, kexec/kdump for PVHVM has well-known issues. You can start reading
from http://lists.xen.org/archives/html/xen-devel/2014-12/msg01312.html
I'm still going to pick this up eventually.

>
> -Stefan
>
> [1] commit 12275dd4b747f5d87fa36229774d76bca8e63068
> Revert "xen/pv-on-hvm kexec: add xs_reset_watches to shutdown watches..."
> [2] commit cb6b6df111e46b9d0f79eb971575fd50555f43f4
> xen/pv-on-hvm kexec: add quirk for Xen 3.4 and shutdown watches.
> ___
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel

-- 
  Vitaly

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


[Xen-devel] Using kexec-crashdump with recent Xen and Linux HVM

2015-03-11 Thread Stefan Bader
After being asked about this I started to play around with Xen-4.4.1/4.5
together with HVM Linux guest running 3.13/3.16/3.19. With mixed success.
Usually rather failing.

From a bit of research most activity to enable things were back in 2011. There
was a bit of a throwback around Linux 3.2[1] but it appears [2] restored this in
a backwards compatible way. Around 3.17 xen_nopv was introduced but I have not
figured out a helpful usage of this.

The failure exhibits no visible messages in the guest after the crash stacktrace
caused by sysreq-trigger while 1vcpu seems to be in a spinning loop. On the host
side I noticed changing messages (TX queue drain or EVCHNOP errors).

Command-line is a mix of nomodeset (to keep cirrusdrm away) and some defaults
from the kdump-tools (maxcpus=1 irqpoll nousb).

The closest thing to success I can get to is using xen_emul_unplug=never for the
normal boot (which propagates into the kexec command). This of course stops
usage of the pv drivers. I also tried some variation of blacklisting the
emulated drivers and using xen_emul_unplug=unnecessary but that did not seem to
work for me. The crash-kexec boot without unplugging still fails to bring up the
NIC but at least finds the root disk to store the dump there. But not using the
pv drivers is not a setup one would want to have running just in case.

So I was wondering whether I still miss something.

-Stefan



[1] commit 12275dd4b747f5d87fa36229774d76bca8e63068
Revert "xen/pv-on-hvm kexec: add xs_reset_watches to shutdown watches..."
[2] commit cb6b6df111e46b9d0f79eb971575fd50555f43f4
xen/pv-on-hvm kexec: add quirk for Xen 3.4 and shutdown watches.



signature.asc
Description: OpenPGP digital signature
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel