FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Redhat > Crash Utility

 
 
LinkBack Thread Tools
 
Old 02-16-2012, 02:31 PM
Dave Anderson
 
Default question about phys_base

----- Original Message -----
> At 02/16/2012 12:17 AM, Dave Anderson Wrote:
> >
> >
> > ----- Original Message -----
> >> Hi, Dave
> >>
> >> I am implementing a new dump command in the qemu. The vmcore's
> >> format is elf(like kdump). And I try to provide phys_base in
> >> the PT_LOAD. But if the os uses the first vcpu do kdump, the
> >> value of phys_base is wrong.
> >>
> >> I find a function x86_64_virt_phys_base() in crash's code.
> >> Is it OK to call this function first? If the function
> >> successes, we do not calculate phys_base according to PT_LOAD.
> >
> > I'm presuming that the qemu-generated ELF file is essentially
> > a "clone" of a kdump ELF file, and therefore the initialization
> > sequence would be:
> >
> > main()
> > machdep_init(PRE_GDB)
> > x86_64_init(PRE_GDB)
> > x86_64_calc_phys_base()
> >
> > where it should fall into this part:
> >
> > if ((vd = get_kdump_vmcore_data())) {
> > for (i = 0; i < vd->num_pt_load_segments; i++) {
> > phdr = vd->load64 + i;
> > if ((phdr->p_vaddr >= __START_KERNEL_map)
> > &&
> > !(IS_VMALLOC_ADDR(phdr->p_vaddr))) {
> >
> > machdep->machspec->phys_base =
> > phdr->p_paddr -
> > (phdr->p_vaddr &
> > ~(__START_KERNEL_map));
> >
> > if (CRASHDEBUG(1)) {
> > fprintf(fp, "p_vaddr: %lx
> > p_paddr: %lx -> ",
> > phdr->p_vaddr,
> > phdr->p_paddr);
> > fprintf(fp, "phys_base:
> > %lx

",
> > machdep->machspec->phys_base);
> > }
> > break;
> > }
> > }
> >
> > return;
> > }
> >
> > Question: will the qemu-generated ELF header contain a PT_LOAD segment that
> > describes the mapped __START_KERNEL_map region?
> >
> > If the __START_KERNEL_map PT_LOAD segment does *not* exist, then the code above
> > would fall through to the "return", and I suppose that you could call
> > x86_64_virt_phys_base() there instead.
> >
> > If there *is* a __START_KERNEL_map PT_LOAD segment, are you saying that
> > the calculation above would incorrectly calculate phys_base?
>
> Because it is hard to calculate phys_base in qemu side. I try to do it like
> the function get_kernel_base() in qemu.c. But if the os uses the vcpu to do
> kdump, the phys_base is for the second kernel, not the first kernel. Another
> problem is that it is for linux, and we donot which the guest is.
>
> >
> > Ideally, there would be some other "differentiator" between qemu-generated
> > and kdump-generated ELF headers -- while still being a KDUMP clone in all
> > other respects. (Maybe an ELF NOTE?) And then preferably, that differentiator
> > could be used to separate the code, i.e., something like:
>
> The qemu-generated ELF headers may be the same as kdump-generated ELF headers.

OK, so then I don't understand what you mean by "may be the same"?

You didn't answer my original question, but if I understand you correctly,
it would be impossible for the qemu host to create a PT_LOAD segment that
describes an x86_64 guest's __START_KERNEL_map region, because the host
doesn't know that what kind of kernel the guest is running.

So that means that qemu-generated ELF header *cannot* be the same
as a kdump-generated ELF header. And for that matter, the same would be
true for x86, although the crash code doesn't use the p_vaddr field from
the ELF header like the x86_64 does.

Dave

>
> Thanks
> Wen Congyang
> >
> > if (qemu_generated_ELF_kdump() {
> > x86_64_virt_phys_base();
> > return;
> > }
> >
> > if ((vd = get_kdump_vmcore_data())) {
> > for (i = 0; i < vd->num_pt_load_segments; i++) {
> > phdr = vd->load64 + i;
> > if ((phdr->p_vaddr >= __START_KERNEL_map)
> > &&
> > ...
> >
> > Would that be possible?
> >
> > Dave
> >
> >
>
>

--
Crash-utility mailing list
Crash-utility@redhat.com
https://www.redhat.com/mailman/listinfo/crash-utility
 
Old 02-16-2012, 02:39 PM
Dave Anderson
 
Default question about phys_base

----- Original Message -----
> From: Wen Congyang <wency@cn.fujitsu.com>
> Subject: Re: question about phys_base
> Date: Thu, 16 Feb 2012 09:16:28 +0800
>
> > At 02/16/2012 12:17 AM, Dave Anderson Wrote:
> >>
> >>
> >> ----- Original Message -----
> >>> Hi, Dave
> >>>
> >>> I am implementing a new dump command in the qemu. The vmcore's
> >>> format is elf(like kdump). And I try to provide phys_base in
> >>> the PT_LOAD. But if the os uses the first vcpu do kdump, the
> >>> value of phys_base is wrong.
> >>>
> >>> I find a function x86_64_virt_phys_base() in crash's code.
> >>> Is it OK to call this function first? If the function
> >>> successes, we do not calculate phys_base according to PT_LOAD.
> >>
> >> I'm presuming that the qemu-generated ELF file is essentially
> >> a "clone" of a kdump ELF file, and therefore the initialization
> >> sequence would be:
> >>
> >> main()
> >> machdep_init(PRE_GDB)
> >> x86_64_init(PRE_GDB)
> >> x86_64_calc_phys_base()
> >>
> >> where it should fall into this part:
> >>
> >> if ((vd = get_kdump_vmcore_data())) {
> >> for (i = 0; i < vd->num_pt_load_segments; i++) {
> >> phdr = vd->load64 + i;
> >> if ((phdr->p_vaddr >= __START_KERNEL_map) &&
> >> !(IS_VMALLOC_ADDR(phdr->p_vaddr))) {
> >>
> >> machdep->machspec->phys_base =
> >> phdr->p_paddr -
> >> (phdr->p_vaddr &
> >> ~(__START_KERNEL_map));
> >>
> >> if (CRASHDEBUG(1)) {
> >> fprintf(fp, "p_vaddr: %lx
> >> p_paddr: %lx -> ",
> >> phdr->p_vaddr,
> >> phdr->p_paddr);
> >> fprintf(fp, "phys_base:
> >> %lx

",
> >> machdep->machspec->phys_base);
> >> }
> >> break;
> >> }
> >> }
> >>
> >> return;
> >> }
> >>
> >> Question: will the qemu-generated ELF header contain a PT_LOAD segment that
> >> describes the mapped __START_KERNEL_map region?
> >>
> >> If the __START_KERNEL_map PT_LOAD segment does *not* exist, then the code above
> >> would fall through to the "return", and I suppose that you could call
> >> x86_64_virt_phys_base() there instead.
> >>
> >> If there *is* a __START_KERNEL_map PT_LOAD segment, are you saying that
> >> the calculation above would incorrectly calculate phys_base?
> >
> > Because it is hard to calculate phys_base in qemu side. I try to do it like
> > the function get_kernel_base() in qemu.c. But if the os uses the vcpu to do
> > kdump, the phys_base is for the second kernel, not the first kernel. Another
> > problem is that it is for linux, and we donot which the guest is.
> >
>
> For the another problem, I don't know whether the way of checking the
> type of running OS that is typically used, exists now, how about
> letting users to specify the format through command-line? For example
> --elf or --os=linux. Users who try to generate vmcore must know what
> kind of OS is running, so I guess they can choose proper ones.
>
> Of couse, if such way exists, it should be used.
>
> >>
> >> Ideally, there would be some other "differentiator" between qemu-generated
> >> and kdump-generated ELF headers -- while still being a KDUMP clone in all
> >> other respects. (Maybe an ELF NOTE?) And then preferably, that differentiator
> >> could be used to separate the code, i.e., something like:
> >
> > The qemu-generated ELF headers may be the same as kdump-generated ELF headers.
> >
> > Thanks
> > Wen Congyang
>
> kdump ELF vmcore has further VMCOREINFO.
>
> $ readelf -n
> /media/pub3/vmcores/vmcore-2.6.35.14-106.fc14.x86_64-10000-threads
>
> Notes at offset 0x000001c8 with length 0x00000838:
> Owner Data size Description
> CORE 0x00000150 NT_PRSTATUS (prstatus structure)
> CORE 0x00000150 NT_PRSTATUS (prstatus structure)
> VMCOREINFO 0x00000557 Unknown note type:
> (0x00000000)
>
> But diskdump/netdump ELF vmcore doesn't, so crash could possibly get
> confused against this.
>
> OTOH, I think qemu's CPU state information, CPUX86State structure, is
> very useful debugging information. Because kvmdump format has the same
> information, if this information is lost, this can be thouht of as a
> kind of feature regression. So, how adding the information as new note
> information? Then, this can help crash to distinguish the vmcore from
> the original kdump's.
>
> Thanks.
> HATAYAMA, Daisuke

Right -- that would be a good idea. In fact I thought I read that
someone on the qemu-devel list had suggested that Wen do just that.

Dave

>
> >>
> >> if (qemu_generated_ELF_kdump() {
> >> x86_64_virt_phys_base();
> >> return;
> >> }
> >>
> >> if ((vd = get_kdump_vmcore_data())) {
> >> for (i = 0; i < vd->num_pt_load_segments; i++) {
> >> phdr = vd->load64 + i;
> >> if ((phdr->p_vaddr >= __START_KERNEL_map)
> >> &&
> >> ...
> >>
> >> Would that be possible?
> >>
> >> Dave
> >>
> >>
> >
> >
>
>

--
Crash-utility mailing list
Crash-utility@redhat.com
https://www.redhat.com/mailman/listinfo/crash-utility
 
Old 02-16-2012, 03:30 PM
Dave Anderson
 
Default question about phys_base

----- Original Message -----
> >
> > OK, so then I don't understand what you mean by "may be the same"?
> >
> > You didn't answer my original question, but if I understand you correctly,
> > it would be impossible for the qemu host to create a PT_LOAD segment that
> > describes an x86_64 guest's __START_KERNEL_map region, because the host
> > doesn't know that what kind of kernel the guest is running.
>
> Yes. Even if the guest is linux, it is still impossible to do it. Because
> the guest maybe in the second kernel.
>
> qemu-dump walks all guest's page table and collect virtual address and
> physical address mapping. If the page is not used by guest, the virtual is set
> to 0. I create PT_LOAD according to such mapping. So if the guest is linux,
> there may be a PT_LOAD segment that describes __START_KERNEL_map region.
> But the information stored in PT_LOAD maybe for the second kernel. If crash
> uses it, crash will see the second kernel, not the first kernel.

Just to be clear -- what do you mean by the "second" kernel? Do you
mean that a guest kernel crashed guest, and did a kdump operation,
and that second kdump kernel failed somehow, and now you're trying
to do a "virsh dump" on the kdump kernel?

Dave

--
Crash-utility mailing list
Crash-utility@redhat.com
https://www.redhat.com/mailman/listinfo/crash-utility
 
Old 02-16-2012, 11:40 PM
Wen Congyang
 
Default question about phys_base

At 02/17/2012 12:30 AM, Dave Anderson Wrote:
>
>
> ----- Original Message -----
>>>
>>> OK, so then I don't understand what you mean by "may be the same"?
>>>
>>> You didn't answer my original question, but if I understand you correctly,
>>> it would be impossible for the qemu host to create a PT_LOAD segment that
>>> describes an x86_64 guest's __START_KERNEL_map region, because the host
>>> doesn't know that what kind of kernel the guest is running.
>>
>> Yes. Even if the guest is linux, it is still impossible to do it. Because
>> the guest maybe in the second kernel.
>>
>> qemu-dump walks all guest's page table and collect virtual address and
>> physical address mapping. If the page is not used by guest, the virtual is set
>> to 0. I create PT_LOAD according to such mapping. So if the guest is linux,
>> there may be a PT_LOAD segment that describes __START_KERNEL_map region.
>> But the information stored in PT_LOAD maybe for the second kernel. If crash
>> uses it, crash will see the second kernel, not the first kernel.
>
> Just to be clear -- what do you mean by the "second" kernel? Do you
> mean that a guest kernel crashed guest, and did a kdump operation,
> and that second kdump kernel failed somehow, and now you're trying
> to do a "virsh dump" on the kdump kernel?

Yes, the second kernel means kdump kernel. If kdump failed, the user can
use it to dump the guest's memory.

Thanks
Wen Congyang

>
> Dave
>

--
Crash-utility mailing list
Crash-utility@redhat.com
https://www.redhat.com/mailman/listinfo/crash-utility

Fri Feb 17 03:30:01 2012
Return-path: <aur-general-bounces@archlinux.org>
Envelope-to: tom@linux-archive.org
Delivery-date: Fri, 17 Feb 2012 02:41:58 +0200
Received: from gerolde.archlinux.org ([66.211.214.132]:60652)
by s2.java-tips.org with esmtp (Exim 4.69)
(envelope-from <aur-general-bounces@archlinux.org>)
id 1RyBte-000210-IW
for tom@linux-archive.org; Fri, 17 Feb 2012 02:41:58 +0200
Received: from gudrun.archlinux.org (gudrun.archlinux.org [66.211.214.131])
by gerolde.archlinux.org (Postfix) with ESMTP id 83355900A5;
Thu, 16 Feb 2012 19:41:50 -0500 (EST)
Received: from gerolde.archlinux.org (gerolde.archlinux.org [66.211.214.132])
by gudrun.archlinux.org (Postfix) with ESMTP id D92E7921A4
for <aur-general@archlinux.org>; Thu, 16 Feb 2012 19:41:48 -0500 (EST)
Received-SPF: pass (gmail.com ... _spf.google.com: 209.85.214.44 is authorized
to use 'techlivezheng@gmail.com' in 'mfrom' identity (mechanism
'ip4:209.85.128.0/17' matched)) receiver=gerolde.archlinux.org;
identity=mailfrom; envelope-from="techlivezheng@gmail.com";
helo=mail-bk0-f44.google.com; client-ip=209.85.214.44
Received: from mail-bk0-f44.google.com (mail-bk0-f44.google.com
[209.85.214.44])
by gerolde.archlinux.org (Postfix) with ESMTPS id 723379009A
for <aur-general@archlinux.org>; Thu, 16 Feb 2012 19:41:47 -0500 (EST)
Received: by bkuw12 with SMTP id w12so2617522bku.3
for <aur-general@archlinux.org>; Thu, 16 Feb 2012 16:41:52 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
h=mime-version:in-reply-to:references:from:date:message-id:subject:to
:content-type:content-transfer-encoding;
bh=2fKj8fIvRqf69wXUV9gfe3nSE4cjzxapAYX9lv6f7/o=;
b=TrFc3zo+3ZvIqOnFuPdyNE8PmPaSi8JLwv61zoRng9eDUESZ RQG58/22AljKys0SAk
JdtvbwniBPMJJCDJp/cC6sleQTm4l744Lvvpp1sOXfP0mMhYZg4/uFJ4uN5JtXlS7+7F
PPqpgbKuT/Mro4Ib0vg2JNeKu7p1pPDJseHJE=
Received: by 10.204.153.195 with SMTP id l3mr3332299bkw.123.1329439312258;
Thu, 16 Feb 2012 16:41:52 -0800 (PST)
MIME-Version: 1.0
Received: by 10.205.143.137 with HTTP; Thu, 16 Feb 2012 16:41:12 -0800 (PST)
In-Reply-To: <CALzgn9v95RFSgQu+x8t-iVK-SsPEjdQGeAZ_Gu2ucs2r61qSdg@mail.gmail.com>
References: <CAPYzjrSFskgQeqMuXJCQL7Gm7hah5WAZecQuBXhvx6asSKjw cw@mail.gmail.com>
<CALzgn9v95RFSgQu+x8t-iVK-SsPEjdQGeAZ_Gu2ucs2r61qSdg@mail.gmail.com>
From: =?UTF-8?B?6YOR5paH6L6JKFRlY2hsaXZlIFpoZW5nKQ==?=
<techlivezheng@gmail.com>
Date: Fri, 17 Feb 2012 08:41:12 +0800
Message-ID: <CAPYzjrQsUbAzWfJsxTSmUpA9CejfdGY7iHLgiBX_Feng_o4S rA@mail.gmail.com>
To: "Discussion about the Arch User Repository (AUR)"
<aur-general@archlinux.org>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Subject: Re: [aur-general] Which aur uploader is better, aurploader or burp?
X-BeenThere: aur-general@archlinux.org
X-Mailman-Version: 2.1.14
Precedence: list
Reply-To: "Discussion about the Arch User Repository (AUR)"
<aur-general@archlinux.org>
List-Id: "Discussion about the Arch User Repository (AUR)"
<aur-general.archlinux.org>
List-Unsubscribe: <http://mailman.archlinux.org/mailman/options/aur-general>,
<mailto:aur-general-request@archlinux.org?subject=unsubscribe>
List-Archive: <http://mailman.archlinux.org/pipermail/aur-general>
List-Post: <mailto:aur-general@archlinux.org>
List-Help: <mailto:aur-general-request@archlinux.org?subject=help>
List-Subscribe: <http://mailman.archlinux.org/mailman/listinfo/aur-general>,
<mailto:aur-general-request@archlinux.org?subject=subscribe>
Errors-To: aur-general-bounces@archlinux.org
Sender: aur-general-bounces@archlinux.org

2012/2/17 Mike Sampson <mike@sambodata.com>:
> 2012/2/17 =E9=83=91=E6=96=87=E8=BE=89(Techlive Zheng) <techlivezheng@gmai=
l.com>:
>> I realize there are two AUR uploader helper, aurploader[1] and
>> burp[2]=EF=BC=9FWhich one is you guys using? What's the pro and con?
>>
> [snip]
>
> I was using aurploader until recently but gave burp a go after I tried
> cower by the same aurthor. I really liked cower and burp looks a
> little more snappy to me than aurploader.
>
> Mike

I am using yaourt for a while and it is painfull to choose between so
much aur helps.

How about cower compare to yaourt?
 
Old 02-17-2012, 01:20 PM
Dave Anderson
 
Default question about phys_base

----- Original Message -----
> At 02/17/2012 12:30 AM, Dave Anderson Wrote:

> >> Yes. Even if the guest is linux, it is still impossible to do it. Because
> >> the guest maybe in the second kernel.
> >>
> >> qemu-dump walks all guest's page table and collect virtual address and
> >> physical address mapping. If the page is not used by guest, the virtual is set
> >> to 0. I create PT_LOAD according to such mapping. So if the guest linux,
> >> there may be a PT_LOAD segment that describes __START_KERNEL_map region.
> >> But the information stored in PT_LOAD maybe for the second kernel. If crash
> >> uses it, crash will see the second kernel, not the first kernel.
> >
> > Just to be clear -- what do you mean by the "second" kernel? Do you
> > mean that a guest kernel crashed guest, and did a kdump operation,
> > and that second kdump kernel failed somehow, and now you're trying
> > to do a "virsh dump" on the kdump kernel?
>
> Yes, the second kernel means kdump kernel. If kdump failed, the user can
> use it to dump the guest's memory.

OK, so will your code present two different "types" of ELF headers?

Dave

--
Crash-utility mailing list
Crash-utility@redhat.com
https://www.redhat.com/mailman/listinfo/crash-utility

Fri Feb 17 16:30:02 2012
Return-path: <arch-general-bounces@archlinux.org>
Envelope-to: tom@linux-archive.org
Delivery-date: Fri, 17 Feb 2012 16:21:07 +0200
Received: from gerolde.archlinux.org ([66.211.214.132]:57076)
by s2.java-tips.org with esmtp (Exim 4.69)
(envelope-from <arch-general-bounces@archlinux.org>)
id 1RyOgN-0004hE-Ov
for tom@linux-archive.org; Fri, 17 Feb 2012 16:21:07 +0200
Received: from gudrun.archlinux.org (gudrun.archlinux.org [66.211.214.131])
by gerolde.archlinux.org (Postfix) with ESMTP id 1D73490081;
Fri, 17 Feb 2012 09:21:06 -0500 (EST)
Received: from gerolde.archlinux.org (gerolde.archlinux.org [66.211.214.132])
by gudrun.archlinux.org (Postfix) with ESMTP id 3045E921A4
for <arch-general@archlinux.org>; Fri, 17 Feb 2012 09:21:04 -0500 (EST)
Received-SPF: pass (gmail.com ... _spf.google.com: 209.85.214.44 is authorized
to use 'techlivezheng@gmail.com' in 'mfrom' identity (mechanism
'ip4:209.85.128.0/17' matched)) receiver=gerolde.archlinux.org;
identity=mailfrom; envelope-from="techlivezheng@gmail.com";
helo=mail-bk0-f44.google.com; client-ip=209.85.214.44
Received: from mail-bk0-f44.google.com (mail-bk0-f44.google.com
[209.85.214.44])
by gerolde.archlinux.org (Postfix) with ESMTPS id CE8D59007A
for <arch-general@archlinux.org>; Fri, 17 Feb 2012 09:21:03 -0500 (EST)
Received: by bkuw12 with SMTP id w12so3027814bku.3
for <arch-general@archlinux.org>; Fri, 17 Feb 2012 06:21:08 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
h=mime-version:in-reply-to:references:from:date:message-id:subject:to
:content-type:content-transfer-encoding;
bh=bMp0xiA9+S5KkQ+4eo0jknReco/gnDFx09RMiG0hEFE=;
b=ajqWetJXN+WDbBkj0ODufPgmabCRUfwEVaHqDydkg1glMDCH 8gxEmfFzCxRkY6jJtc
9k6S3Z+xXKNYlaWAlyEEn4soUR8y88kFBHG5D5cluoCjqOTbhc 05BPV86x3AtUYuTk53
7jecuQ4voT8un20dtkPOfe0oRFA+9xRJpWVlw=
Received: by 10.204.155.77 with SMTP id r13mr4333488bkw.105.1329488468233;
Fri, 17 Feb 2012 06:21:08 -0800 (PST)
MIME-Version: 1.0
Received: by 10.205.143.137 with HTTP; Fri, 17 Feb 2012 06:20:27 -0800 (PST)
In-Reply-To: <CAExbbMxFNLiUZEh9B1oiMRCGvuN+geNgtqc6K+yF5oyAY22x 3A@mail.gmail.com>
References: <CABr5rzJem1DBK87T4piYsD70TkJzZEdjUFctkKKeOvJp3gAy Gg@mail.gmail.com>
<CAPYzjrSngBEuARE3CnvhY-HiaM0nyFvrOwL6g-K0+4H11x55XA@mail.gmail.com>
<20120217065736.GA28183@blizzard>
<CABr5rz+6WtBuebH_UQh-bWVtCc86dUbR8rYx-i6bmn9x-76jPA@mail.gmail.com>
<20120217094838.GB4887@blizzard>
<CAPYzjrQ7GpcjzFeZ6_5GqjnzwEtqViCqQsD_QCT423AvSKuo 9g@mail.gmail.com>
<20120217110324.GA8229@blizzard> <20120217111818.GA14270@blizzard>
<CAExbbMxFNLiUZEh9B1oiMRCGvuN+geNgtqc6K+yF5oyAY22x 3A@mail.gmail.com>
From: =?UTF-8?B?6YOR5paH6L6JKFRlY2hsaXZlIFpoZW5nKQ==?=
<techlivezheng@gmail.com>
Date: Fri, 17 Feb 2012 22:20:27 +0800
Message-ID: <CAPYzjrREC6NpaxTsg2z++9GrmvtKNbOijVLLrQ-x=NfJABdEqg@mail.gmail.com>
To: General Discussion about Arch Linux <arch-general@archlinux.org>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Subject: Re: [arch-general] Start a daemon, show a syntax error
X-BeenThere: arch-general@archlinux.org
X-Mailman-Version: 2.1.14
Precedence: list
Reply-To: General Discussion about Arch Linux <arch-general@archlinux.org>
List-Id: General Discussion about Arch Linux <arch-general.archlinux.org>
List-Unsubscribe: <http://mailman.archlinux.org/mailman/options/arch-general>,
<mailto:arch-general-request@archlinux.org?subject=unsubscribe>
List-Archive: <http://mailman.archlinux.org/pipermail/arch-general>
List-Post: <mailto:arch-general@archlinux.org>
List-Help: <mailto:arch-general-request@archlinux.org?subject=help>
List-Subscribe: <http://mailman.archlinux.org/mailman/listinfo/arch-general>,
<mailto:arch-general-request@archlinux.org?subject=subscribe>
Errors-To: arch-general-bounces@archlinux.org
Sender: arch-general-bounces@archlinux.org

My default shell is bash.But I am not sure which shell it is using or
under which mode of the bash while the system is starting.How to
ensure that?

2012/2/17 SanskritFritz <sanskritfritz@gmail.com>:
> On Fri, Feb 17, 2012 at 12:18 PM, Lukas Fleischer
> <archlinux@cryptocrack.de> wrote:
>>> a) You're not using bash (e.g. running rc.d(8) in sh(1)/$whatever).
>>> b) You built bash manually and disabled process substitution support.
>>> c) You're running bash in POSIX mode.
>>> d) Something else happened.
>>
>> e) Someone hacked into your system and changed the shebang of all daemon
>> =A0 scripts to "#!/bin/sh".
>
> Maybe
> f) Your default shell is not bash?
 
Old 02-24-2012, 07:07 AM
Wen Congyang
 
Default question about phys_base

At 02/17/2012 10:20 PM, Dave Anderson Wrote:
>
>
> ----- Original Message -----
>> At 02/17/2012 12:30 AM, Dave Anderson Wrote:
>
>>>> Yes. Even if the guest is linux, it is still impossible to do it. Because
>>>> the guest maybe in the second kernel.
>>>>
>>>> qemu-dump walks all guest's page table and collect virtual address and
>>>> physical address mapping. If the page is not used by guest, the virtual is set
>>>> to 0. I create PT_LOAD according to such mapping. So if the guest linux,
>>>> there may be a PT_LOAD segment that describes __START_KERNEL_map region.
>>>> But the information stored in PT_LOAD maybe for the second kernel. If crash
>>>> uses it, crash will see the second kernel, not the first kernel.
>>>
>>> Just to be clear -- what do you mean by the "second" kernel? Do you
>>> mean that a guest kernel crashed guest, and did a kdump operation,
>>> and that second kdump kernel failed somehow, and now you're trying
>>> to do a "virsh dump" on the kdump kernel?
>>
>> Yes, the second kernel means kdump kernel. If kdump failed, the user can
>> use it to dump the guest's memory.
>
> OK, so will your code present two different "types" of ELF headers?

I donot understand what do you want to say.
Do you mean there is two ELF headers in qemu-generated vmcore?

Thanks
Wen Congyang

>
> Dave
>

--
Crash-utility mailing list
Crash-utility@redhat.com
https://www.redhat.com/mailman/listinfo/crash-utility
 
Old 02-24-2012, 12:37 PM
Dave Anderson
 
Default question about phys_base

----- Original Message -----
> At 02/17/2012 10:20 PM, Dave Anderson Wrote:
> >
> >
> > ----- Original Message -----
> >> At 02/17/2012 12:30 AM, Dave Anderson Wrote:
> >
> >>>> Yes. Even if the guest is linux, it is still impossible to do it. Because
> >>>> the guest maybe in the second kernel.
> >>>>
> >>>> qemu-dump walks all guest's page table and collect virtual address and
> >>>> physical address mapping. If the page is not used by guest, the virtual is set
> >>>> to 0. I create PT_LOAD according to such mapping. So if the guest linux,
> >>>> there may be a PT_LOAD segment that describes __START_KERNEL_map region.
> >>>> But the information stored in PT_LOAD maybe for the second. If crash
> >>>> uses it, crash will see the second kernel, not the first kernel.
> >>>
> >>> Just to be clear -- what do you mean by the "second" kernel? Do you
> >>> mean that a guest kernel crashed guest, and did a kdump operation,
> >>> and that second kdump kernel failed somehow, and now you're trying
> >>> to do a "virsh dump" on the kdump kernel?
> >>
> >> Yes, the second kernel means kdump kernel. If kdump failed, the user can
> >> use it to dump the guest's memory.
> >
> > OK, so will your code present two different "types" of ELF headers?
>
> I donot understand what do you want to say.
> Do you mean there is two ELF headers in qemu-generated vmcore?

No. What I want to understand is how x86_64_calc_phys_base() will
be able to confidently recognize that an ELF file was qemu-generated,
so that it can then do the right thing.

And from your description, it sounds like there will be different PT_LOAD
descriptors based upon whether it's the first or second kernel. And
the difference between the two would be based upon which (if any) of the
following statements are true:

(1) first kernel -- contains a valid __START_KERNEL_map PT_LOAD segment
(2) first kernel -- does *not* contain a __START_KERNEL_map PT_LOAD segment
(3) second kernel -- contains an invalid (first kernel) __START_KERNEL_map PT_LOAD segment
(4) second kernel -- does *not* contain a __START_KERNEL_map PT_LOAD segment
(5) ???

What will differentiate qemu-generated ELF headers from kdump-generated ELF
headers?

Dave

--
Crash-utility mailing list
Crash-utility@redhat.com
https://www.redhat.com/mailman/listinfo/crash-utility
 
Old 02-27-2012, 12:01 AM
Wen Congyang
 
Default question about phys_base

At 02/24/2012 09:37 PM, Dave Anderson Wrote:
>
>
> ----- Original Message -----
>> At 02/17/2012 10:20 PM, Dave Anderson Wrote:
>>>
>>>
>>> ----- Original Message -----
>>>> At 02/17/2012 12:30 AM, Dave Anderson Wrote:
>>>
>>>>>> Yes. Even if the guest is linux, it is still impossible to do it. Because
>>>>>> the guest maybe in the second kernel.
>>>>>>
>>>>>> qemu-dump walks all guest's page table and collect virtual address and
>>>>>> physical address mapping. If the page is not used by guest, the virtual is set
>>>>>> to 0. I create PT_LOAD according to such mapping. So if the guest linux,
>>>>>> there may be a PT_LOAD segment that describes __START_KERNEL_map region.
>>>>>> But the information stored in PT_LOAD maybe for the second. If crash
>>>>>> uses it, crash will see the second kernel, not the first kernel.
>>>>>
>>>>> Just to be clear -- what do you mean by the "second" kernel? Do you
>>>>> mean that a guest kernel crashed guest, and did a kdump operation,
>>>>> and that second kdump kernel failed somehow, and now you're trying
>>>>> to do a "virsh dump" on the kdump kernel?
>>>>
>>>> Yes, the second kernel means kdump kernel. If kdump failed, the user can
>>>> use it to dump the guest's memory.
>>>
>>> OK, so will your code present two different "types" of ELF headers?
>>
>> I donot understand what do you want to say.
>> Do you mean there is two ELF headers in qemu-generated vmcore?
>
> No. What I want to understand is how x86_64_calc_phys_base() will
> be able to confidently recognize that an ELF file was qemu-generated,
> so that it can then do the right thing.
>
> And from your description, it sounds like there will be different PT_LOAD
> descriptors based upon whether it's the first or second kernel. And
> the difference between the two would be based upon which (if any) of the
> following statements are true:
>
> (1) first kernel -- contains a valid __START_KERNEL_map PT_LOAD segment
> (2) first kernel -- does *not* contain a __START_KERNEL_map PT_LOAD segment
> (3) second kernel -- contains an invalid (first kernel) __START_KERNEL_map PT_LOAD segment
> (4) second kernel -- does *not* contain a __START_KERNEL_map PT_LOAD segment
> (5) ???

The guest is in first kernel:
# readelf /tmp/vm2.save -l| grep 0xffffffff8
LOAD 0x00000000010226b8 0xffffffff81000000 0x0000000001000000
LOAD 0x00000000010226b8 0xffffffff81000000 0x0000000001000000
LOAD 0x00000000010226b8 0xffffffff81000000 0x0000000001000000
LOAD 0x00000000010226b8 0xffffffff81000000 0x0000000001000000

The guest is in the second kernel(vcpu > 1)
]# readelf /tmp/vm2.save2 -l| grep 0xffffffff8
LOAD 0x0000000001017be0 0xffffffff81000000 0x0000000001000000
LOAD 0x0000000001017be0 0xffffffff81000000 0x0000000001000000
LOAD 0x0000000001017be0 0xffffffff81000000 0x0000000001000000
LOAD 0x0000000004017be0 0xffffffff81000000 0x0000000004000000

The guest is in the second kernel(vcpu = 1)
[root@ghost ~]# readelf /tmp/vm2.save3 -l| grep 0xffffffff8
LOAD 0x0000000004001e4c 0xffffffff81000000 0x0000000004000000

I donot find differentiate qemu-genetated ELF headers from dump-generated ELF
headers.

Thanks
Wen Congyang
>
> What will differentiate qemu-generated ELF headers from kdump-generated ELF
> headers?
>
> Dave
>

--
Crash-utility mailing list
Crash-utility@redhat.com
https://www.redhat.com/mailman/listinfo/crash-utility
 
Old 02-27-2012, 01:10 PM
Dave Anderson
 
Default question about phys_base

----- Original Message -----
> >
> > No. What I want to understand is how x86_64_calc_phys_base() will
> > be able to confidently recognize that an ELF file was qemu-generated,
> > so that it can then do the right thing.

> The guest is in first kernel:
> # readelf /tmp/vm2.save -l| grep 0xffffffff8
> LOAD 0x00000000010226b8 0xffffffff81000000 0x0000000001000000
> LOAD 0x00000000010226b8 0xffffffff81000000 0x0000000001000000
> LOAD 0x00000000010226b8 0xffffffff81000000 0x0000000001000000
> LOAD 0x00000000010226b8 0xffffffff81000000 0x0000000001000000

Why are there multiple segments describing the same virtual/physical region?
Is there one START_KERNEL_map segment for each vcpu? Are their FileSiz/MemSiz
values all the same?

> The guest is in the second kernel(vcpu > 1)
> ]# readelf /tmp/vm2.save2 -l| grep 0xffffffff8
> LOAD 0x0000000001017be0 0xffffffff81000000 0x0000000001000000
> LOAD 0x0000000001017be0 0xffffffff81000000 0x0000000001000000
> LOAD 0x0000000001017be0 0xffffffff81000000 0x0000000001000000
> LOAD 0x0000000004017be0 0xffffffff81000000 0x0000000004000000

Again, it's not clear why there are multiple segments with the same
same virtual address, but I'm guessing that the one segment that starts
at 0x0000000004000000 is associated with the second kernel, and the other
ones are for vcpus that ran in the first kernel?

> The guest is in the second kernel(vcpu = 1)
> [root@ghost ~]# readelf /tmp/vm2.save3 -l| grep 0xffffffff8
> LOAD 0x0000000004001e4c 0xffffffff81000000 0x0000000004000000
>
> I donot find differentiate qemu-genetated ELF headers from dump-generated ELF
> headers.

Kdump-generated vmcores cannot have multiple START_KERNEL_map segments.
But with dumps where (vpcu = 1), there could be confusion since it's not obvious
if START_KERNEL_map region belongs to the first or second kernel.

That being the case, I don't see how this can be supported cleanly by the crash'
utility unless there is a NOTE, or some other obvious identifier, that absolutely
confirms that the dumpfile was qemu-generated.

Dave





--
Crash-utility mailing list
Crash-utility@redhat.com
https://www.redhat.com/mailman/listinfo/crash-utility
 
Old 02-28-2012, 04:10 AM
Wen Congyang
 
Default question about phys_base

At 02/27/2012 10:10 PM, Dave Anderson Wrote:
>
>
> ----- Original Message -----
>>>
>>> No. What I want to understand is how x86_64_calc_phys_base() will
>>> be able to confidently recognize that an ELF file was qemu-generated,
>>> so that it can then do the right thing.
>
>> The guest is in first kernel:
>> # readelf /tmp/vm2.save -l| grep 0xffffffff8
>> LOAD 0x00000000010226b8 0xffffffff81000000 0x0000000001000000
>> LOAD 0x00000000010226b8 0xffffffff81000000 0x0000000001000000
>> LOAD 0x00000000010226b8 0xffffffff81000000 0x0000000001000000
>> LOAD 0x00000000010226b8 0xffffffff81000000 0x0000000001000000
>
> Why are there multiple segments describing the same virtual/physical region?
> Is there one START_KERNEL_map segment for each vcpu? Are their FileSiz/MemSiz
> values all the same?

Thanks for pointing this problem. I update the qemu side's patch:
The guest is in first kernel(vcpu: 4):
# readelf /tmp/vm2.save -l| grep 0xffffffff8
LOAD 0x000000000100f360 0xffffffff81000000 0x0000000001000000

The guest is in the second kernel(vcpu: 4)
# readelf /tmp/vm2.save2 -l| grep 0xffffffff8
LOAD 0x000000000100eb10 0xffffffff81000000 0x0000000001000000
LOAD 0x000000000400eb10 0xffffffff81000000 0x0000000004000000

The guest is in the second kernel(vcpu: 1)
[root@ghost ~]# readelf /tmp/vm2.save3 -l| grep 0xffffffff8
LOAD 0x0000000004001cfc 0xffffffff81000000 0x0000000004000000


>
>> The guest is in the second kernel(vcpu > 1)
>> ]# readelf /tmp/vm2.save2 -l| grep 0xffffffff8
>> LOAD 0x0000000001017be0 0xffffffff81000000 0x0000000001000000
>> LOAD 0x0000000001017be0 0xffffffff81000000 0x0000000001000000
>> LOAD 0x0000000001017be0 0xffffffff81000000 0x0000000001000000
>> LOAD 0x0000000004017be0 0xffffffff81000000 0x0000000004000000
>
> Again, it's not clear why there are multiple segments with the same
> same virtual address, but I'm guessing that the one segment that starts
> at 0x0000000004000000 is associated with the second kernel, and the other
> ones are for vcpus that ran in the first kernel?
>
>> The guest is in the second kernel(vcpu = 1)
>> [root@ghost ~]# readelf /tmp/vm2.save3 -l| grep 0xffffffff8
>> LOAD 0x0000000004001e4c 0xffffffff81000000 0x0000000004000000
>>
>> I donot find differentiate qemu-genetated ELF headers from dump-generated ELF
>> headers.
>
> Kdump-generated vmcores cannot have multiple START_KERNEL_map segments.
> But with dumps where (vpcu = 1), there could be confusion since it's not obvious
> if START_KERNEL_map region belongs to the first or second kernel.
>
> That being the case, I don't see how this can be supported cleanly by the crash'
> utility unless there is a NOTE, or some other obvious identifier, that absolutely
> confirms that the dumpfile was qemu-generated.

The note information stored in qemu-generated core:
Program Headers:
Type Offset VirtAddr PhysAddr
FileSiz MemSiz Flags Align
NOTE 0x000000000000edd0 0x0000000000000000 0x0000000000000000
0x0000000000000590 0x0000000000000590 0

I think its format is the same as kdump's vmcore. Does kdump-generated core's
virtaddr is always 0? If so, What about to set virt_addr to -1 in qemu-generated
core?

Thanks
Wen Congyang

>
> Dave
>
>
>
>
>
>

--
Crash-utility mailing list
Crash-utility@redhat.com
https://www.redhat.com/mailman/listinfo/crash-utility
 

Thread Tools




All times are GMT. The time now is 11:27 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org