From: Ian Campbell <Ian.Campbell@citrix.com>
To: M A Young <m.a.young@durham.ac.uk>
Cc: George Dunlap <George.Dunlap@eu.citrix.com>,
Ian Jackson <ian.jackson@eu.citrix.com>,
Wei Liu <Wei.Liu2@citrix.com>,
"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: Problems using xl migrate
Date: Mon, 24 Nov 2014 12:21:22 +0000 [thread overview]
Message-ID: <1416831682.8878.1.camel@citrix.com> (raw)
In-Reply-To: <alpine.GSO.2.00.1411241203280.1328@algedi.dur.ac.uk>
On Mon, 2014-11-24 at 12:06 +0000, M A Young wrote:
>
> On Mon, 24 Nov 2014, George Dunlap wrote:
>
> > On Mon, Nov 24, 2014 at 12:07 AM, M A Young <m.a.young@durham.ac.uk> wrote:
> >> On Sat, 22 Nov 2014, M A Young wrote:
> >>
> >>> While investigating a bug reported on Red Hat Bugzilla
> >>> https://bugzilla.redhat.com/show_bug.cgi?id=1166461
> >>> I discovered the following
> >>>
> >>> xl migrate --debug domid localhost does indeed fail for Xen 4.4 pv (the
> >>> bug report is for Xen 4.3 hvm ) when xl migrate domid localhost works. There
> >>> are actually two issues here
> >>>
> >>> * the segfault in libxl-save-helper --restore-domain (as reported in the
> >>> bug above) occurs if the guest memory is 1024M (on my 4G box) and is
> >>> presumably because the allocated memory eventually runs out
> >>
> >>
> >> I have found a bit more out about this. The segfault at at line 1378 of
> >> tools/libxc/xc_domain_restore.c which is
> >> DPRINTF("************** pfn=%lx type=%lx gotcs=%08lx "
> >> "actualcs=%08lx\n", pfn, pagebuf->pfn_types[pfn],
> >> csum_page(region_base + (i + curbatch)*PAGE_SIZE),
> >> csum_page(buf));
> >> and is because pfn in pagebuf->pfn_types[pfn] is beyond the end of the
> >> array. This occurs in the verification phase.
> >>
> >>> * the segfault doesn't occur if the guest memory is 128M, but the
> >>> migration still fails. The first attached file contains the log from a run
> >>> with xl -v migrate --debug domid localhost (with mfn and duplicated lines
> >>> stripped out to make the size manageable).
> >>
> >>
> >> The difference actually seems to be down to how active the VM is rather than
> >> the memory size (my small memory test system was doing very little, my
> >> larger system was a full OS install). In the non-segfault case the problem
> >> was the printf and printf_info commands in the create_domain() routine in
> >> tools/libxl/xl_cmdimpl.c . As xl migrate uses stdout to pass status messages
> >> back from the restoring dom0, these commands cause an unexpected message. If
> >> you move them onto stderr then the migration completes in the non-segfault
> >> case.
> >
> > Good job tracking those down -- are there patches in the works?
>
> I have a partial patch for the printf printf_info problem, which works for
> me but doesn't cover printing the info in sxp format.
Am I right that is all related to the use of --debug and or -vm? and
that a plain "xl migrate" works ok?
It's still a bug of course, but changes the severity (somehow, not sure
to what extent IMHO it does etc).
> I haven't worked out
> what is leading up to the segfault yet.
>
> Michael Young
next prev parent reply other threads:[~2014-11-24 12:21 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-11-22 19:24 Problems using xl migrate M A Young
2014-11-24 0:07 ` M A Young
2014-11-24 11:50 ` George Dunlap
2014-11-24 12:06 ` M A Young
2014-11-24 12:21 ` Ian Campbell [this message]
2014-11-24 12:29 ` M A Young
2014-11-24 13:13 ` Andrew Cooper
2014-11-24 14:09 ` Wei Liu
2014-11-24 14:13 ` Andrew Cooper
2014-11-25 8:52 ` M A Young
2014-11-25 9:15 ` Wei Liu
2014-11-25 22:16 ` M A Young
2014-11-25 22:32 ` Andrew Cooper
2014-11-24 12:25 ` George Dunlap
2014-11-24 12:41 ` Wei Liu
2014-11-24 13:15 ` Andrew Cooper
2014-11-24 14:32 ` (4.5-rc1) " M A Young
2014-11-24 14:43 ` Andrew Cooper
2014-11-24 14:55 ` Ian Campbell
2014-11-24 19:28 ` Daniel De Graaf
2014-11-24 20:12 ` M A Young
2014-11-24 22:05 ` Daniel De Graaf
2014-11-25 10:07 ` George Dunlap
2014-11-25 18:03 ` Daniel De Graaf
2014-11-25 18:17 ` Konrad Rzeszutek Wilk
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1416831682.8878.1.camel@citrix.com \
--to=ian.campbell@citrix.com \
--cc=George.Dunlap@eu.citrix.com \
--cc=Wei.Liu2@citrix.com \
--cc=ian.jackson@eu.citrix.com \
--cc=m.a.young@durham.ac.uk \
--cc=xen-devel@lists.xen.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.