From mboxrd@z Thu Jan  1 00:00:00 1970
From: Dan Magenheimer <dan.magenheimer@oracle.com>
Subject: RE: pv 2.6.31 (kernel.org) and save/migrate
Date: Sat, 7 Nov 2009 07:32:49 -0800 (PST)
Message-ID: <373a54d1-3dec-4185-b1ca-0363e14329b4@default>
References: <20091107110905.GB1434@reaktio.net>
Mime-Version: 1.0
Content-Type: text/plain; charset=Windows-1252
Content-Transfer-Encoding: quoted-printable
Return-path: <xen-devel-bounces@lists.xensource.com>
In-Reply-To: <20091107110905.GB1434@reaktio.net>
List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com
To: =?UTF-8?B?IlBhc2kgS8Okcmtrw6RpbmVuIg==?= <pasik@iki.fi>
Cc: "Xen-Devel (E-mail)" <xen-devel@lists.xensource.com>
List-Id: xen-devel@lists.xenproject.org

> > Well, first, I got 2.6.31.5 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=3Dy... don't
> > know if that is important.)
>=20
> I'll have to try it later today..

Let me know.

> > (On the machine I couldn't boot 2.6.31.5 as a PV guest, there
> > was absolutely no console output.  However, I think tools
> > are out-of-date on that machine so ignore that.)
>=20
> Did you have "console=3Dhvc0 earlyprintk=3Dxen" 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=3Dpreserve and then when the PV guest is crashed run this:
>=20
> /usr/lib/xen/bin/xenctx -s System.map-domUkernelversion <domid>
>=20
> (if you have 64b host the xenctx binary might be under /usr/lib64/)
>=20
> 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=20
flags: 00001206 i nz p
ss:esp: e021:c0779ee4
eax: 00000001=09ebx: 00000002=09ecx: 00000100=09edx: 00000001
esi: c0779f1c=09edi: c0779f18=09ebp: c0779f24
 ds:     e021=09 es:     e021=09 fs:     00d8=09 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 8=
b 04 24 89 18 89 0e 89=20


Stack:
 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=20
  [<c0670ed8>] init_intel+0x140=20
  [<c066fe6a>] init_scattered_cpuid_features+0x82=20
  [<c06705e2>] identify_cpu+0x22d=20
  [<c040584c>] xen_force_evtchn_callback+0xc=20
  [<c0405e78>] check_events+0x8=20
  [<c07c9dec>] identify_boot_cpu+0xa=20
  [<c07c9e9a>] check_bugs+0x8=20
  [<c07c27bd>] start_kernel+0x2a0=20
  [<c07c5206>] xen_start_kernel+0x340=20