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 01-01-1970, 01:00 AM
HATAYAMA Daisuke
 
Default question about phys_base

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

>>
>> 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 01-01-1970, 01:00 AM
HATAYAMA Daisuke
 
Default question about phys_base

From: Dave Anderson <anderson@redhat.com>
Subject: Re: question about phys_base
Date: Thu, 16 Feb 2012 10:39:04 -0500 (EST)

>
>
> ----- 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
>

Thanks. I've just noticed. I've not read the thread yet. That's better.

Thanks.
HATAYAMA, Daisuke

--
Crash-utility mailing list
Crash-utility@redhat.com
https://www.redhat.com/mailman/listinfo/crash-utility
 
Old 01-01-1970, 01:00 AM
HATAYAMA Daisuke
 
Default question about phys_base

From: Wen Congyang <wency@cn.fujitsu.com>
Subject: Re: [Crash-utility] question about phys_base
Date: Tue, 28 Feb 2012 13:10:38 +0800

> At 02/27/2012 10:10 PM, Dave Anderson Wrote:

>>> 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?
>

In general, such characteristic should not be used. You should prepare
a solid interface. Even if using them, it should be limited to as
workaround to avoid some issue.

Why not use qemu's CPU state? Include it as note information with good
name, and we can use it to distinguish which. Like:

$ readelf -n vmcore

Notes at offset 0x000001c8 with length 0x00000838:
Owner Data size Description
CORE 0x00000150 NT_PRSTATUS (prstatus structure)
CORE 0x00000150 NT_PRSTATUS (prstatus structure)
QEMU 0x00000557 Unknown note type: (0x00000000)

Or QEMUCPUState is better?

Thanks.
HATAYAMA, Daisuke

--
Crash-utility mailing list
Crash-utility@redhat.com
https://www.redhat.com/mailman/listinfo/crash-utility
 
Old 01-01-1970, 01:00 AM
HATAYAMA Daisuke
 
Default question about phys_base

From: Wen Congyang <wency@cn.fujitsu.com>
Subject: Re: [Crash-utility] question about phys_base
Date: Tue, 28 Feb 2012 16:36:59 +0800

> At 02/28/2012 02:30 PM, HATAYAMA Daisuke Wrote:
>> From: Wen Congyang <wency@cn.fujitsu.com>
>> Subject: Re: [Crash-utility] question about phys_base
>> Date: Tue, 28 Feb 2012 13:10:38 +0800
>>
>>> At 02/27/2012 10:10 PM, Dave Anderson Wrote:
>>
>>>>> 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?
>>>
>>
>> In general, such characteristic should not be used. You should prepare
>> a solid interface. Even if using them, it should be limited to as
>> workaround to avoid some issue.
>>
>> Why not use qemu's CPU state? Include it as note information with good
>> name, and we can use it to distinguish which. Like:
>>
>> $ readelf -n vmcore
>>
>> Notes at offset 0x000001c8 with length 0x00000838:
>> Owner Data size Description
>> CORE 0x00000150 NT_PRSTATUS (prstatus structure)
>> CORE 0x00000150 NT_PRSTATUS (prstatus structure)
>> QEMU 0x00000557 Unknown note type: (0x00000000)
>>
>> Or QEMUCPUState is better?
>
> Good idea. I will try it, and hope gdb can also work.
>

Tools basically ignore unknown notes. Looking into gdb, it appears to
ignore unknown information.

static bfd_boolean
elfcore_grok_note (bfd *abfd, Elf_Internal_Note *note)
{
const struct elf_backend_data *bed = get_elf_backend_data (abfd);

switch (note->type)
{
default:
return TRUE;
<cut>

You might need to add new command to output contents of new note if
it's necessary.

Thanks.
HATAYAMA, Daisuke

--
Crash-utility mailing list
Crash-utility@redhat.com
https://www.redhat.com/mailman/listinfo/crash-utility
 
Old 01-01-1970, 01:00 AM
HATAYAMA Daisuke
 
Default question about phys_base

From: Wen Congyang <wency@cn.fujitsu.com>
Subject: Re: [Crash-utility] question about phys_base
Date: Tue, 28 Feb 2012 17:04:30 +0800

> At 02/28/2012 04:52 PM, HATAYAMA Daisuke Wrote:
>> From: Wen Congyang <wency@cn.fujitsu.com>
>> Subject: Re: [Crash-utility] question about phys_base
>> Date: Tue, 28 Feb 2012 16:36:59 +0800
>>
>>> At 02/28/2012 02:30 PM, HATAYAMA Daisuke Wrote:
>>>> From: Wen Congyang <wency@cn.fujitsu.com>
>>>> Subject: Re: [Crash-utility] question about phys_base
>>>> Date: Tue, 28 Feb 2012 13:10:38 +0800
>>>>
>>>>> At 02/27/2012 10:10 PM, Dave Anderson Wrote:
>>>>
>>>>>>> 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?
>>>>>
>>>>
>>>> In general, such characteristic should not be used. You should prepare
>>>> a solid interface. Even if using them, it should be limited to as
>>>> workaround to avoid some issue.
>>>>
>>>> Why not use qemu's CPU state? Include it as note information with good
>>>> name, and we can use it to distinguish which. Like:
>>>>
>>>> $ readelf -n vmcore
>>>>
>>>> Notes at offset 0x000001c8 with length 0x00000838:
>>>> Owner Data size Description
>>>> CORE 0x00000150 NT_PRSTATUS (prstatus structure)
>>>> CORE 0x00000150 NT_PRSTATUS (prstatus structure)
>>>> QEMU 0x00000557 Unknown note type: (0x00000000)
>>>>
>>>> Or QEMUCPUState is better?
>>>
>>> Good idea. I will try it, and hope gdb can also work.
>>>
>>
>> Tools basically ignore unknown notes. Looking into gdb, it appears to
>> ignore unknown information.
>>
>> static bfd_boolean
>> elfcore_grok_note (bfd *abfd, Elf_Internal_Note *note)
>> {
>> const struct elf_backend_data *bed = get_elf_backend_data (abfd);
>>
>> switch (note->type)
>> {
>> default:
>> return TRUE;
>> <cut>
>>
>> You might need to add new command to output contents of new note if
>> it's necessary.
>
> My goal is:
> 1. gdb uses NT_PRSTATUS, and can work well
> 2. crash uses unknown notes, and can get phys_base from it.
>
> Another question:
>
> What is QEMUCPUState? I donot find its definition?
> What note->type shoule be for "QEMU"? If we choose an unused value, the
> value may be used in the future.

For QEMUCPUState, I mean CPUState type information in qemu. It has
machine state information and is very useful for debugging. QEMU
maintainer says it's necessary and I thought adding this note is
natural story.

If adding this in dumpfile, we can at least do the same thing as
kvmdump to calculate phys_base.

To make this note as meaningful as we can say ``gdb works well',
command to display CPUState is needed. Just like registers command.

(gdb) info registers
rax 0x10 16
rbx 0x63 99
rcx 0x1194 4500
rdx 0x0 0
rsi 0x0 0
rdi 0x63 99
rbp 0xffff88012187be48 0xffff88012187be48
rsp 0xffff88012187be48 0xffff88012187be48
r8 0x0 0
r9 0xffffffffffffffff -1
r10 0xffff88013fc06000 -131936030793728

These values can be referenced with notation $rax, so it would be
happier if able to do the same thing for QEMUCPUState, but not
definite if too complicated to implement.

That's all for idea I have for gdb now.

Thanks.
HATAYAMA, Daisuke

--
Crash-utility mailing list
Crash-utility@redhat.com
https://www.redhat.com/mailman/listinfo/crash-utility
 
Old 01-01-1970, 01:00 AM
HATAYAMA Daisuke
 
Default question about phys_base

From: Dave Anderson <anderson@redhat.com>
Subject: Re: [Crash-utility] question about phys_base
Date: Tue, 28 Feb 2012 09:44:09 -0500 (EST)

>
>
> ----- Original Message -----
>> At 02/28/2012 04:52 PM, HATAYAMA Daisuke Wrote:
>
>> >>> In general, such characteristic should not be used. You should prepare
>> >>> a solid interface. Even if using them, it should be limited to as
>> >>> workaround to avoid some issue.
>> >>>
>> >>> Why not use qemu's CPU state? Include it as note information with good
>> >>> name, and we can use it to distinguish which. Like:
>> >>>
>> >>> $ readelf -n vmcore
>> >>>
>> >>> Notes at offset 0x000001c8 with length 0x00000838:
>> >>> Owner Data size Description
>> >>> CORE 0x00000150 NT_PRSTATUS (prstatus structure)
>> >>> CORE 0x00000150 NT_PRSTATUS (prstatus structure)
>> >>> QEMU 0x00000557 Unknown note type: (0x00000000)
>> >>>
>> >>> Or QEMUCPUState is better?
>> >>
>> >> Good idea. I will try it, and hope gdb can also work.
>> >>
>> >
>> > Tools basically ignore unknown notes. Looking into gdb, it appears to
>> > ignore unknown information.
>> >
>> > static bfd_boolean
>> > elfcore_grok_note (bfd *abfd, Elf_Internal_Note *note)
>> > {
>> > const struct elf_backend_data *bed = get_elf_backend_data (abfd);
>> >
>> > switch (note->type)
>> > {
>> > default:
>> > return TRUE;
>> > <cut>
>> >
>> > You might need to add new command to output contents of new note if
>> > it's necessary.
>>
>> My goal is:
>> 1. gdb uses NT_PRSTATUS, and can work well
>> 2. crash uses unknown notes, and can get phys_base from it.
>>
>> Another question:
>>
>> What is QEMUCPUState? I donot find its definition?
>
> It's just the note's name character string. Either "QEMU", "QEMUCPUState",
> or whatever unique character string you prefer would suffice.
>
>> What note->type shoule be for "QEMU"? If we choose an unused value, the
>> value may be used in the future.
>
> Why not do the same thing as the "VMCOREINFO" note, and leave it
> as an "illegal/unknown" type of 0::
>
> $ cat /usr/include/elf.h
> ... [ cut ] ...
>
> /* Legal values for note segment descriptor types for core files. */
>
> #define NT_PRSTATUS 1 /* Contains copy of prstatus struct */
> #define NT_FPREGSET 2 /* Contains copy of fpregset struct */
> #define NT_PRPSINFO 3 /* Contains copy of prpsinfo struct */
> ...
> $
>
> $ readelf -a vmcore
> ... [ cut ] ...
>
> Notes at offset 0x00000190 with length 0x00000f1c:
> Owner Data size Description
> CORE 0x00000150 NT_PRSTATUS (prstatus structure)
> CORE 0x00000150 NT_PRSTATUS (prstatus structure)
> CORE 0x00000150 NT_PRSTATUS (prstatus structure)
> CORE 0x00000150 NT_PRSTATUS (prstatus structure)
> CORE 0x00000150 NT_PRSTATUS (prstatus structure)
> CORE 0x00000150 NT_PRSTATUS (prstatus structure)
> CORE 0x00000150 NT_PRSTATUS (prstatus structure)
> CORE 0x00000150 NT_PRSTATUS (prstatus structure)
> VMCOREINFO 0x000003e4 Unknown note type: (0x00000000)
> $
>

It looks OK to me for now.

But rigorously, it might be better to give it a name QEMU and then
prepare variety of information such as NT_CPUSTATE and others to be
needed later.

Thanks.
HATAYAMA, Daisuke

--
Crash-utility mailing list
Crash-utility@redhat.com
https://www.redhat.com/mailman/listinfo/crash-utility
 
Old 01-01-1970, 01:00 AM
HATAYAMA Daisuke
 
Default question about phys_base

From: Wen Congyang <wency@cn.fujitsu.com>
Subject: Re: [Crash-utility] question about phys_base
Date: Wed, 29 Feb 2012 14:01:44 +0800

> At 02/29/2012 09:04 AM, HATAYAMA Daisuke Wrote:
>> From: Dave Anderson <anderson@redhat.com>
>> Subject: Re: [Crash-utility] question about phys_base
>> Date: Tue, 28 Feb 2012 09:44:09 -0500 (EST)
>>
>>>
>>>
>>> ----- Original Message -----
>>>> At 02/28/2012 04:52 PM, HATAYAMA Daisuke Wrote:
>>>
>>>>>>> In general, such characteristic should not be used. You should prepare
>>>>>>> a solid interface. Even if using them, it should be limited to as
>>>>>>> workaround to avoid some issue.
>>>>>>>
>>>>>>> Why not use qemu's CPU state? Include it as note information with good
>>>>>>> name, and we can use it to distinguish which. Like:
>>>>>>>
>>>>>>> $ readelf -n vmcore
>>>>>>>
>>>>>>> Notes at offset 0x000001c8 with length 0x00000838:
>>>>>>> Owner Data size Description
>>>>>>> CORE 0x00000150 NT_PRSTATUS (prstatus structure)
>>>>>>> CORE 0x00000150 NT_PRSTATUS (prstatus structure)
>>>>>>> QEMU 0x00000557 Unknown note type: (0x00000000)
>>>>>>>
>>>>>>> Or QEMUCPUState is better?
>>>>>>
>>>>>> Good idea. I will try it, and hope gdb can also work.
>>>>>>
>>>>>
>>>>> Tools basically ignore unknown notes. Looking into gdb, it appears to
>>>>> ignore unknown information.
>>>>>
>>>>> static bfd_boolean
>>>>> elfcore_grok_note (bfd *abfd, Elf_Internal_Note *note)
>>>>> {
>>>>> const struct elf_backend_data *bed = get_elf_backend_data (abfd);
>>>>>
>>>>> switch (note->type)
>>>>> {
>>>>> default:
>>>>> return TRUE;
>>>>> <cut>
>>>>>
>>>>> You might need to add new command to output contents of new note if
>>>>> it's necessary.
>>>>
>>>> My goal is:
>>>> 1. gdb uses NT_PRSTATUS, and can work well
>>>> 2. crash uses unknown notes, and can get phys_base from it.
>>>>
>>>> Another question:
>>>>
>>>> What is QEMUCPUState? I donot find its definition?
>>>
>>> It's just the note's name character string. Either "QEMU", "QEMUCPUState",
>>> or whatever unique character string you prefer would suffice.
>>>
>>>> What note->type shoule be for "QEMU"? If we choose an unused value, the
>>>> value may be used in the future.
>>>
>>> Why not do the same thing as the "VMCOREINFO" note, and leave it
>>> as an "illegal/unknown" type of 0::
>>>
>>> $ cat /usr/include/elf.h
>>> ... [ cut ] ...
>>>
>>> /* Legal values for note segment descriptor types for core files. */
>>>
>>> #define NT_PRSTATUS 1 /* Contains copy of prstatus struct */
>>> #define NT_FPREGSET 2 /* Contains copy of fpregset struct */
>>> #define NT_PRPSINFO 3 /* Contains copy of prpsinfo struct */
>>> ...
>>> $
>>>
>>> $ readelf -a vmcore
>>> ... [ cut ] ...
>>>
>>> Notes at offset 0x00000190 with length 0x00000f1c:
>>> Owner Data size Description
>>> CORE 0x00000150 NT_PRSTATUS (prstatus structure)
>>> CORE 0x00000150 NT_PRSTATUS (prstatus structure)
>>> CORE 0x00000150 NT_PRSTATUS (prstatus structure)
>>> CORE 0x00000150 NT_PRSTATUS (prstatus structure)
>>> CORE 0x00000150 NT_PRSTATUS (prstatus structure)
>>> CORE 0x00000150 NT_PRSTATUS (prstatus structure)
>>> CORE 0x00000150 NT_PRSTATUS (prstatus structure)
>>> CORE 0x00000150 NT_PRSTATUS (prstatus structure)
>>> VMCOREINFO 0x000003e4 Unknown note type: (0x00000000)
>>> $
>>>
>>
>> It looks OK to me for now.
>>
>> But rigorously, it might be better to give it a name QEMU and then
>> prepare variety of information such as NT_CPUSTATE and others to be
>> needed later.
>
> I see. I think we should decide what information should be stored in QEMUCPUState.
> The CPUState in qemu cannot be used directly, because it may be changed in the furture.
> I think all CPU register should be stored in QEMUCPUState. Do we need other information?
>

For future incompatibility of CPUState, I think it useful to design
note information so that what kinds of values are contained there, for
example, by appending versions indicating that uniquely in the
begginning of the data.

Now the things I come up with are the CPUState only. I think it's
better for you to make the question on qemu mailing list too.

Thanks.
HATAYAMA, Daisuke

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

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.

Thanks
Wen Congyang

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

----- 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?

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:

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, 12:16 AM
Wen Congyang
 
Default question about phys_base

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.

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
 

Thread Tools




All times are GMT. The time now is 03:56 AM.

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