This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Home Products Support Community News


RE: [Xen-devel] pv 2.6.31 (kernel.org) and save/migrate

To: "Pasi Kärkkäinen" <pasik@xxxxxx>
Subject: RE: [Xen-devel] pv 2.6.31 (kernel.org) and save/migrate
From: Dan Magenheimer <dan.magenheimer@xxxxxxxxxx>
Date: Sat, 7 Nov 2009 07:32:49 -0800 (PST)
Cc: "Xen-Devel \(E-mail\)" <xen-devel@xxxxxxxxxxxxxxxxxxx>
Delivery-date: Sat, 07 Nov 2009 07:34:14 -0800
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <20091107110905.GB1434@xxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
> > Well, first, I got to boot in a PV guest in another
> > machine and it fails to save also.  Are you able to save
> > 2.6.31{,.5} successfully?  On latest xen-unstable?
> > (NOTE: Yes, I do have CONFIG_XEN_SAVE_RESTORE=y... don't
> > know if that is important.)
> I'll have to try it later today..

Let me know.

> > (On the machine I couldn't boot as a PV guest, there
> > was absolutely no console output.  However, I think tools
> > are out-of-date on that machine so ignore that.)
> Did you have "console=hvc0 earlyprintk=xen" in the domU kernel
> parameters?

No, but that didn't work either.

> You might also change the xen guest cfgfile so that you have
> on_crash=preserve and then when the PV guest is crashed run this:
> /usr/lib/xen/bin/xenctx -s System.map-domUkernelversion <domid>
> (if you have 64b host the xenctx binary might be under /usr/lib64/)
> to get a stack trace..

Very interesting and useful!  I was completely unaware of
xenctx and could have used it many times in tmem development!

The results explain why I can get it to run on
one machine (an older laptop) and not run on another
machine (a Nehalem system)... looks like this is maybe
related to the cpuid-extended-topology-leaf bug that Jeremy
sent a fix for upstream recently.

cs:eip: e019:c040342d xen_cpuid+0x46 
flags: 00001206 i nz p
ss:esp: e021:c0779ee4
eax: 00000001   ebx: 00000002   ecx: 00000100   edx: 00000001
esi: c0779f1c   edi: c0779f18   ebp: c0779f24
 ds:     e021    es:     e021    fs:     00d8    gs:     0000
Code (instr addr c040342d)
24 04 8b 15 a4 02 7c c0 89 54 24 08 8b 0e 0f 0b 78 65 6e 0f a2 <89> 45 00 8b 04 
24 89 18 89 0e 89 

 c0779f20 ffffffff ffffffff c07c0360 c0779f18 c0779f1c c0779f20 c066fd0f
 c0779f18 c0779f24 00000002 16aee301 00000001 00000001 16aee301 00000002
 0000000b c07c03cc c07c0360 c07c0360 c07c03d8 c0670ed8 c0779f58 00000001
 c07c0360 c0779f60 c066fe6a c0779f60 c0779f60 00000003 00000001 00000000

Call Trace:
  [<c040342d>] xen_cpuid+0x46  <--
  [<c066fd0f>] detect_extended_topology+0xae 
  [<c0670ed8>] init_intel+0x140 
  [<c066fe6a>] init_scattered_cpuid_features+0x82 
  [<c06705e2>] identify_cpu+0x22d 
  [<c040584c>] xen_force_evtchn_callback+0xc 
  [<c0405e78>] check_events+0x8 
  [<c07c9dec>] identify_boot_cpu+0xa 
  [<c07c9e9a>] check_bugs+0x8 
  [<c07c27bd>] start_kernel+0x2a0 
  [<c07c5206>] xen_start_kernel+0x340 

Xen-devel mailing list