From: Petr Tesarik <ptesarik@suse.cz>
To: "Trapp, Norbert" <norbert.trapp@ts.fujitsu.com>
Cc: kexec@lists.infradead.org
Subject: Re: [patch 8/9] Add support for filtering out user pages under Xen4
Date: Thu, 23 Aug 2012 17:49:44 +0200 [thread overview]
Message-ID: <201208231749.45081.ptesarik@suse.cz> (raw)
In-Reply-To: <201208231410.21324.ptesarik@suse.cz>
Dne Čt 23. srpna 2012 14:10:21 jste napsal(a):
> Dne Čt 23. srpna 2012 12:00:41 jste napsal(a):
> > Hello Petr,
> >
> > Actually we didn't need to patch the crash utility for the SLES11 SP1
> > version we use. When I call the crash utility with the vmcore.d0 argument
> >
> > that your current makedumpfile version produces, I see:
> > WARNING: crashing_cpu not found.
> > crash: invalid kernel virtual address: 0 type: "opt_sched,"
> >
> > crash: cannot read opt_sched,.
Hello Norbert once again,
I've investigated the logic once more, and we should probably rethink what
we're filtering out for "-X". The manual page says:
-X Exclude all the user domain pages from Xen kdump's VMCORE, and
extracts the part of xen and domain-0.
So, depending on how I read it, it should either:
a. throw away anything but dom_xen, dom_io and dom0, or
b. keep everything except domU
I vote for a, because it should give the smallest dump. Now, all such pages
will have:
1. PGC_allocated (it is allocated to a domain)
2. one of the 3 known values for _domain
All else only adds unnecessary complexity. But even that does not cover all
cases. For example the "opt_sched" (actually ops.opt_name) is stored at
physical address 0x3fa38b28 (PFN 0x3fa38), but frame_table[0x3fa38] is:
struct page_info {
{
list = {
next = 0,
prev = 0
},
up = 0,
shr_handle = 0
},
count_info = 0,
u = {
inuse = {
type_info = 0
},
sh = {
type = 0,
pinned = 0,
count = 0
},
free = {
need_tlbflush = 0 '\000'
}
},
v = {
inuse = {
_domain = 0
},
sh = {
back = 0
},
free = {
order = 0
}
},
{
tlbflush_timestamp = 0,
{
nr_validated_ptes = 0,
partial_pte = 0 '\000'
},
shadow_flags = 0,
next_shadow = 0
}
}
This looks pretty uninitialized to me. Your patch keeps this page, because you
don't filter out anything that has PGC_allocated==0 and PGC_state_inuse
(numerically 0), but I'm not sure that's right.
I'll try asking on the Xen mailing list about the intended hierarchy of the
various PGC_xxx flags.
Petr Tesarik
SUSE Linux
_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
next parent reply other threads:[~2012-08-23 15:49 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <0E9227E8EFCFF54EA493F6C0399C015D3996033588@ABGEX70E.FSC.NET>
[not found] ` <0E9227E8EFCFF54EA493F6C0399C015D39960338DA@ABGEX70E.FSC.NET>
[not found] ` <201208231410.21324.ptesarik@suse.cz>
2012-08-23 15:49 ` Petr Tesarik [this message]
2012-08-21 8:44 [patch 0/9] Support Xen versions up to xen-4.1 Petr Tesarik
2012-08-21 8:44 ` [patch 8/9] Add support for filtering out user pages under Xen4 Petr Tesarik
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=201208231749.45081.ptesarik@suse.cz \
--to=ptesarik@suse.cz \
--cc=kexec@lists.infradead.org \
--cc=norbert.trapp@ts.fujitsu.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox