| Message ID | 4F509E6F.9060801@cn.fujitsu.com |
|---|---|
| State | New |
| Headers | show |
From: Wen Congyang <wency@cn.fujitsu.com> Subject: [RFC][PATCH 05/16 v8] Add API to get memory mapping Date: Fri, 02 Mar 2012 18:18:23 +0800 > Add API to get all virtual address and physical address mapping. > If there is no virtual address for some physical address, the virtual > address is 0. > > Signed-off-by: Wen Congyang <wency@cn.fujitsu.com> > --- > memory_mapping.c | 88 ++++++++++++++++++++++++++++++++++++++++++++++++++++++ > memory_mapping.h | 8 +++++ > 2 files changed, 96 insertions(+), 0 deletions(-) > > diff --git a/memory_mapping.c b/memory_mapping.c > index 718f271..f74c5d0 100644 > --- a/memory_mapping.c > +++ b/memory_mapping.c > @@ -164,3 +164,91 @@ void memory_mapping_list_init(MemoryMappingList *list) > list->last_mapping = NULL; > QTAILQ_INIT(&list->head); > } > + > +int qemu_get_guest_memory_mapping(MemoryMappingList *list) > +{ > + CPUState *env; > + MemoryMapping *memory_mapping; > + RAMBlock *block; > + ram_addr_t offset, length, m_length; > + target_phys_addr_t m_phys_addr; > + int ret; > + bool paging_mode; > + > +#if defined(CONFIG_HAVE_GET_MEMORY_MAPPING) > + paging_mode = cpu_paging_enabled(first_cpu); > + if (paging_mode) { > + for (env = first_cpu; env != NULL; env = env->next_cpu) { > + ret = cpu_get_memory_mapping(list, env); > + if (ret < 0) { > + return -1; > + } > + } > + } > +#else > + return -2; > +#endif > + > + /* > + * some memory may be not in the memory mapping's list: > + * 1. the guest doesn't use paging > + * 2. the guest is in 2nd kernel, and the memory used by 1st kernel is not > + * in paging table > + * add them into memory mapping's list > + */ > + QLIST_FOREACH(block, &ram_list.blocks, next) { How does the memory portion referenced by PT_LOAD program headers with p_vaddr == 0 looks through gdb? If we cannot access such portions, part not referenced by the page table CR3 has is unnecessary, isn't it? Thanks. HATAYAMA, Daisuke
At 03/07/2012 11:27 PM, HATAYAMA Daisuke Wrote: > From: Wen Congyang <wency@cn.fujitsu.com> > Subject: [RFC][PATCH 05/16 v8] Add API to get memory mapping > Date: Fri, 02 Mar 2012 18:18:23 +0800 > >> Add API to get all virtual address and physical address mapping. >> If there is no virtual address for some physical address, the virtual >> address is 0. >> >> Signed-off-by: Wen Congyang <wency@cn.fujitsu.com> >> --- >> memory_mapping.c | 88 ++++++++++++++++++++++++++++++++++++++++++++++++++++++ >> memory_mapping.h | 8 +++++ >> 2 files changed, 96 insertions(+), 0 deletions(-) >> >> diff --git a/memory_mapping.c b/memory_mapping.c >> index 718f271..f74c5d0 100644 >> --- a/memory_mapping.c >> +++ b/memory_mapping.c >> @@ -164,3 +164,91 @@ void memory_mapping_list_init(MemoryMappingList *list) >> list->last_mapping = NULL; >> QTAILQ_INIT(&list->head); >> } >> + >> +int qemu_get_guest_memory_mapping(MemoryMappingList *list) >> +{ >> + CPUState *env; >> + MemoryMapping *memory_mapping; >> + RAMBlock *block; >> + ram_addr_t offset, length, m_length; >> + target_phys_addr_t m_phys_addr; >> + int ret; >> + bool paging_mode; >> + >> +#if defined(CONFIG_HAVE_GET_MEMORY_MAPPING) >> + paging_mode = cpu_paging_enabled(first_cpu); >> + if (paging_mode) { >> + for (env = first_cpu; env != NULL; env = env->next_cpu) { >> + ret = cpu_get_memory_mapping(list, env); >> + if (ret < 0) { >> + return -1; >> + } >> + } >> + } >> +#else >> + return -2; >> +#endif >> + >> + /* >> + * some memory may be not in the memory mapping's list: >> + * 1. the guest doesn't use paging >> + * 2. the guest is in 2nd kernel, and the memory used by 1st kernel is not >> + * in paging table >> + * add them into memory mapping's list >> + */ >> + QLIST_FOREACH(block, &ram_list.blocks, next) { > > How does the memory portion referenced by PT_LOAD program headers with > p_vaddr == 0 looks through gdb? If we cannot access such portions, > part not referenced by the page table CR3 has is unnecessary, isn't > it? The part is unnecessary if you use gdb. But it is necessary if you use crash. Thanks Wen Congyang > > Thanks. > HATAYAMA, Daisuke > >
From: Wen Congyang <wency@cn.fujitsu.com> Subject: Re: [RFC][PATCH 05/16 v8] Add API to get memory mapping Date: Thu, 08 Mar 2012 16:52:29 +0800 > At 03/07/2012 11:27 PM, HATAYAMA Daisuke Wrote: >> From: Wen Congyang <wency@cn.fujitsu.com> >> Subject: [RFC][PATCH 05/16 v8] Add API to get memory mapping >> Date: Fri, 02 Mar 2012 18:18:23 +0800 >> >>> Add API to get all virtual address and physical address mapping. >>> If there is no virtual address for some physical address, the virtual >>> address is 0. >>> >>> Signed-off-by: Wen Congyang <wency@cn.fujitsu.com> >>> --- >>> memory_mapping.c | 88 ++++++++++++++++++++++++++++++++++++++++++++++++++++++ >>> memory_mapping.h | 8 +++++ >>> 2 files changed, 96 insertions(+), 0 deletions(-) >>> >>> diff --git a/memory_mapping.c b/memory_mapping.c >>> index 718f271..f74c5d0 100644 >>> --- a/memory_mapping.c >>> +++ b/memory_mapping.c >>> @@ -164,3 +164,91 @@ void memory_mapping_list_init(MemoryMappingList *list) >>> list->last_mapping = NULL; >>> QTAILQ_INIT(&list->head); >>> } >>> + >>> +int qemu_get_guest_memory_mapping(MemoryMappingList *list) >>> +{ >>> + CPUState *env; >>> + MemoryMapping *memory_mapping; >>> + RAMBlock *block; >>> + ram_addr_t offset, length, m_length; >>> + target_phys_addr_t m_phys_addr; >>> + int ret; >>> + bool paging_mode; >>> + >>> +#if defined(CONFIG_HAVE_GET_MEMORY_MAPPING) >>> + paging_mode = cpu_paging_enabled(first_cpu); >>> + if (paging_mode) { >>> + for (env = first_cpu; env != NULL; env = env->next_cpu) { >>> + ret = cpu_get_memory_mapping(list, env); >>> + if (ret < 0) { >>> + return -1; >>> + } >>> + } >>> + } >>> +#else >>> + return -2; >>> +#endif >>> + >>> + /* >>> + * some memory may be not in the memory mapping's list: >>> + * 1. the guest doesn't use paging >>> + * 2. the guest is in 2nd kernel, and the memory used by 1st kernel is not >>> + * in paging table >>> + * add them into memory mapping's list >>> + */ >>> + QLIST_FOREACH(block, &ram_list.blocks, next) { >> >> How does the memory portion referenced by PT_LOAD program headers with >> p_vaddr == 0 looks through gdb? If we cannot access such portions, >> part not referenced by the page table CR3 has is unnecessary, isn't >> it? > > The part is unnecessary if you use gdb. But it is necessary if you use crash. > crash users would not use paging option because even if without using it, we can see all memory well, so the paging option is only for gdb users. It looks to me that the latter part only complicates the logic. If instead, collecting virtual addresses only, way of handling PT_LOAD entries become simpler, for example, they no longer need to be physically contiguous in a single entry, and reviewing and maintaince becomes easy. Thanks. HATAYAMA, Daisuke
At 03/09/2012 08:40 AM, HATAYAMA Daisuke Wrote: > From: Wen Congyang <wency@cn.fujitsu.com> > Subject: Re: [RFC][PATCH 05/16 v8] Add API to get memory mapping > Date: Thu, 08 Mar 2012 16:52:29 +0800 > >> At 03/07/2012 11:27 PM, HATAYAMA Daisuke Wrote: >>> From: Wen Congyang <wency@cn.fujitsu.com> >>> Subject: [RFC][PATCH 05/16 v8] Add API to get memory mapping >>> Date: Fri, 02 Mar 2012 18:18:23 +0800 >>> >>>> Add API to get all virtual address and physical address mapping. >>>> If there is no virtual address for some physical address, the virtual >>>> address is 0. >>>> >>>> Signed-off-by: Wen Congyang <wency@cn.fujitsu.com> >>>> --- >>>> memory_mapping.c | 88 ++++++++++++++++++++++++++++++++++++++++++++++++++++++ >>>> memory_mapping.h | 8 +++++ >>>> 2 files changed, 96 insertions(+), 0 deletions(-) >>>> >>>> diff --git a/memory_mapping.c b/memory_mapping.c >>>> index 718f271..f74c5d0 100644 >>>> --- a/memory_mapping.c >>>> +++ b/memory_mapping.c >>>> @@ -164,3 +164,91 @@ void memory_mapping_list_init(MemoryMappingList *list) >>>> list->last_mapping = NULL; >>>> QTAILQ_INIT(&list->head); >>>> } >>>> + >>>> +int qemu_get_guest_memory_mapping(MemoryMappingList *list) >>>> +{ >>>> + CPUState *env; >>>> + MemoryMapping *memory_mapping; >>>> + RAMBlock *block; >>>> + ram_addr_t offset, length, m_length; >>>> + target_phys_addr_t m_phys_addr; >>>> + int ret; >>>> + bool paging_mode; >>>> + >>>> +#if defined(CONFIG_HAVE_GET_MEMORY_MAPPING) >>>> + paging_mode = cpu_paging_enabled(first_cpu); >>>> + if (paging_mode) { >>>> + for (env = first_cpu; env != NULL; env = env->next_cpu) { >>>> + ret = cpu_get_memory_mapping(list, env); >>>> + if (ret < 0) { >>>> + return -1; >>>> + } >>>> + } >>>> + } >>>> +#else >>>> + return -2; >>>> +#endif >>>> + >>>> + /* >>>> + * some memory may be not in the memory mapping's list: >>>> + * 1. the guest doesn't use paging >>>> + * 2. the guest is in 2nd kernel, and the memory used by 1st kernel is not >>>> + * in paging table >>>> + * add them into memory mapping's list >>>> + */ >>>> + QLIST_FOREACH(block, &ram_list.blocks, next) { >>> >>> How does the memory portion referenced by PT_LOAD program headers with >>> p_vaddr == 0 looks through gdb? If we cannot access such portions, >>> part not referenced by the page table CR3 has is unnecessary, isn't >>> it? >> >> The part is unnecessary if you use gdb. But it is necessary if you use crash. >> > > crash users would not use paging option because even if without using > it, we can see all memory well, so the paging option is only for gdb > users. Yes, the paging option is only for gdb users. The default value if off. > > It looks to me that the latter part only complicates the logic. If > instead, collecting virtual addresses only, way of handling PT_LOAD > entries become simpler, for example, they no longer need to be > physically contiguous in a single entry, and reviewing and maintaince > becomes easy. Sorry, I donot understand what do you want to say. Thanks Wen Congyang > > Thanks. > HATAYAMA, Daisuke > >
From: Wen Congyang <wency@cn.fujitsu.com> Subject: Re: [RFC][PATCH 05/16 v8] Add API to get memory mapping Date: Fri, 09 Mar 2012 09:46:31 +0800 > At 03/09/2012 08:40 AM, HATAYAMA Daisuke Wrote: >> From: Wen Congyang <wency@cn.fujitsu.com> >> Subject: Re: [RFC][PATCH 05/16 v8] Add API to get memory mapping >> Date: Thu, 08 Mar 2012 16:52:29 +0800 >> >>> At 03/07/2012 11:27 PM, HATAYAMA Daisuke Wrote: >>>> From: Wen Congyang <wency@cn.fujitsu.com> >>>> Subject: [RFC][PATCH 05/16 v8] Add API to get memory mapping >>>> Date: Fri, 02 Mar 2012 18:18:23 +0800 >>>> >>>> >>>> How does the memory portion referenced by PT_LOAD program headers with >>>> p_vaddr == 0 looks through gdb? If we cannot access such portions, >>>> part not referenced by the page table CR3 has is unnecessary, isn't >>>> it? >>> >>> The part is unnecessary if you use gdb. But it is necessary if you use crash. >>> >> >> crash users would not use paging option because even if without using >> it, we can see all memory well, so the paging option is only for gdb >> users. > > Yes, the paging option is only for gdb users. The default value if off. > >> >> It looks to me that the latter part only complicates the logic. If >> instead, collecting virtual addresses only, way of handling PT_LOAD >> entries become simpler, for example, they no longer need to be >> physically contiguous in a single entry, and reviewing and maintaince >> becomes easy. > > Sorry, I donot understand what do you want to say. > The processing that adds part not referenced by page table to vmcore is meaningless for gdb. crash doesn't require it. So, it only complicates the current logic. Thanks. HATAYAMA, Daisuke
At 03/09/2012 10:05 AM, HATAYAMA Daisuke Wrote: > From: Wen Congyang <wency@cn.fujitsu.com> > Subject: Re: [RFC][PATCH 05/16 v8] Add API to get memory mapping > Date: Fri, 09 Mar 2012 09:46:31 +0800 > >> At 03/09/2012 08:40 AM, HATAYAMA Daisuke Wrote: >>> From: Wen Congyang <wency@cn.fujitsu.com> >>> Subject: Re: [RFC][PATCH 05/16 v8] Add API to get memory mapping >>> Date: Thu, 08 Mar 2012 16:52:29 +0800 >>> >>>> At 03/07/2012 11:27 PM, HATAYAMA Daisuke Wrote: >>>>> From: Wen Congyang <wency@cn.fujitsu.com> >>>>> Subject: [RFC][PATCH 05/16 v8] Add API to get memory mapping >>>>> Date: Fri, 02 Mar 2012 18:18:23 +0800 >>>>> >>>>> > >>>>> How does the memory portion referenced by PT_LOAD program headers with >>>>> p_vaddr == 0 looks through gdb? If we cannot access such portions, >>>>> part not referenced by the page table CR3 has is unnecessary, isn't >>>>> it? >>>> >>>> The part is unnecessary if you use gdb. But it is necessary if you use crash. >>>> >>> >>> crash users would not use paging option because even if without using >>> it, we can see all memory well, so the paging option is only for gdb >>> users. >> >> Yes, the paging option is only for gdb users. The default value if off. >> >>> >>> It looks to me that the latter part only complicates the logic. If >>> instead, collecting virtual addresses only, way of handling PT_LOAD >>> entries become simpler, for example, they no longer need to be >>> physically contiguous in a single entry, and reviewing and maintaince >>> becomes easy. >> >> Sorry, I donot understand what do you want to say. >> > > The processing that adds part not referenced by page table to vmcore > is meaningless for gdb. crash doesn't require it. So, it only > complicates the current logic. If the paging mode is on, we can also use crash to analyze the vmcore. As the comment methioned, the memory used by the 1st kernel may be not referenced by the page table, so we neet this logic. Thanks Wen Congyang > > Thanks. > HATAYAMA, Daisuke > >
From: Wen Congyang <wency@cn.fujitsu.com> Subject: Re: [RFC][PATCH 05/16 v8] Add API to get memory mapping Date: Fri, 09 Mar 2012 10:26:56 +0800 > At 03/09/2012 10:05 AM, HATAYAMA Daisuke Wrote: >> From: Wen Congyang <wency@cn.fujitsu.com> >> Subject: Re: [RFC][PATCH 05/16 v8] Add API to get memory mapping >> Date: Fri, 09 Mar 2012 09:46:31 +0800 >> >>> At 03/09/2012 08:40 AM, HATAYAMA Daisuke Wrote: >>>> From: Wen Congyang <wency@cn.fujitsu.com> >>>> Subject: Re: [RFC][PATCH 05/16 v8] Add API to get memory mapping >>>> Date: Thu, 08 Mar 2012 16:52:29 +0800 >>>> >>>>> At 03/07/2012 11:27 PM, HATAYAMA Daisuke Wrote: >>>>>> From: Wen Congyang <wency@cn.fujitsu.com> >>>>>> Subject: [RFC][PATCH 05/16 v8] Add API to get memory mapping >>>>>> Date: Fri, 02 Mar 2012 18:18:23 +0800 >>>>>> >>>>>> >> >>>>>> How does the memory portion referenced by PT_LOAD program headers with >>>>>> p_vaddr == 0 looks through gdb? If we cannot access such portions, >>>>>> part not referenced by the page table CR3 has is unnecessary, isn't >>>>>> it? >>>>> >>>>> The part is unnecessary if you use gdb. But it is necessary if you use crash. >>>>> >>>> >>>> crash users would not use paging option because even if without using >>>> it, we can see all memory well, so the paging option is only for gdb >>>> users. >>> >>> Yes, the paging option is only for gdb users. The default value if off. >>> >>>> >>>> It looks to me that the latter part only complicates the logic. If >>>> instead, collecting virtual addresses only, way of handling PT_LOAD >>>> entries become simpler, for example, they no longer need to be >>>> physically contiguous in a single entry, and reviewing and maintaince >>>> becomes easy. >>> >>> Sorry, I donot understand what do you want to say. >>> >> >> The processing that adds part not referenced by page table to vmcore >> is meaningless for gdb. crash doesn't require it. So, it only >> complicates the current logic. > > If the paging mode is on, we can also use crash to analyze the vmcore. > As the comment methioned, the memory used by the 1st kernel may be not > referenced by the page table, so we neet this logic. > As I said several times, crash users don't use paging mode. Users of the paging mode is gdb only just as you say. So, the paging path needs to collect part referenced by page table only since the other part is invisible to gdb. Thanks. HATAYAMA, Daisuke
On 2012-03-09 03:53, HATAYAMA Daisuke wrote: > From: Wen Congyang <wency@cn.fujitsu.com> > Subject: Re: [RFC][PATCH 05/16 v8] Add API to get memory mapping > Date: Fri, 09 Mar 2012 10:26:56 +0800 > >> At 03/09/2012 10:05 AM, HATAYAMA Daisuke Wrote: >>> From: Wen Congyang <wency@cn.fujitsu.com> >>> Subject: Re: [RFC][PATCH 05/16 v8] Add API to get memory mapping >>> Date: Fri, 09 Mar 2012 09:46:31 +0800 >>> >>>> At 03/09/2012 08:40 AM, HATAYAMA Daisuke Wrote: >>>>> From: Wen Congyang <wency@cn.fujitsu.com> >>>>> Subject: Re: [RFC][PATCH 05/16 v8] Add API to get memory mapping >>>>> Date: Thu, 08 Mar 2012 16:52:29 +0800 >>>>> >>>>>> At 03/07/2012 11:27 PM, HATAYAMA Daisuke Wrote: >>>>>>> From: Wen Congyang <wency@cn.fujitsu.com> >>>>>>> Subject: [RFC][PATCH 05/16 v8] Add API to get memory mapping >>>>>>> Date: Fri, 02 Mar 2012 18:18:23 +0800 >>>>>>> >>>>>>> >>> >>>>>>> How does the memory portion referenced by PT_LOAD program headers with >>>>>>> p_vaddr == 0 looks through gdb? If we cannot access such portions, >>>>>>> part not referenced by the page table CR3 has is unnecessary, isn't >>>>>>> it? >>>>>> >>>>>> The part is unnecessary if you use gdb. But it is necessary if you use crash. >>>>>> >>>>> >>>>> crash users would not use paging option because even if without using >>>>> it, we can see all memory well, so the paging option is only for gdb >>>>> users. >>>> >>>> Yes, the paging option is only for gdb users. The default value if off. >>>> >>>>> >>>>> It looks to me that the latter part only complicates the logic. If >>>>> instead, collecting virtual addresses only, way of handling PT_LOAD >>>>> entries become simpler, for example, they no longer need to be >>>>> physically contiguous in a single entry, and reviewing and maintaince >>>>> becomes easy. >>>> >>>> Sorry, I donot understand what do you want to say. >>>> >>> >>> The processing that adds part not referenced by page table to vmcore >>> is meaningless for gdb. crash doesn't require it. So, it only >>> complicates the current logic. >> >> If the paging mode is on, we can also use crash to analyze the vmcore. >> As the comment methioned, the memory used by the 1st kernel may be not >> referenced by the page table, so we neet this logic. >> > > As I said several times, crash users don't use paging mode. Users of > the paging mode is gdb only just as you say. So, the paging path needs > to collect part referenced by page table only since the other part is > invisible to gdb. If crash can work both with and without paging, it should be default *on* to avoid writing cores that can later on only be analyzed with that tool. Still not sure, though, if that changes the requirement on what memory regions should be written in that mode. Jan
On 2012-03-09 03:53, HATAYAMA Daisuke wrote: > From: Wen Congyang <wency@cn.fujitsu.com> > Subject: Re: [RFC][PATCH 05/16 v8] Add API to get memory mapping > Date: Fri, 09 Mar 2012 10:26:56 +0800 > >> At 03/09/2012 10:05 AM, HATAYAMA Daisuke Wrote: >>> From: Wen Congyang <wency@cn.fujitsu.com> >>> Subject: Re: [RFC][PATCH 05/16 v8] Add API to get memory mapping >>> Date: Fri, 09 Mar 2012 09:46:31 +0800 >>> >>>> At 03/09/2012 08:40 AM, HATAYAMA Daisuke Wrote: >>>>> From: Wen Congyang <wency@cn.fujitsu.com> >>>>> Subject: Re: [RFC][PATCH 05/16 v8] Add API to get memory mapping >>>>> Date: Thu, 08 Mar 2012 16:52:29 +0800 >>>>> >>>>>> At 03/07/2012 11:27 PM, HATAYAMA Daisuke Wrote: >>>>>>> From: Wen Congyang <wency@cn.fujitsu.com> >>>>>>> Subject: [RFC][PATCH 05/16 v8] Add API to get memory mapping >>>>>>> Date: Fri, 02 Mar 2012 18:18:23 +0800 >>>>>>> >>>>>>> >>> >>>>>>> How does the memory portion referenced by PT_LOAD program headers with >>>>>>> p_vaddr == 0 looks through gdb? If we cannot access such portions, >>>>>>> part not referenced by the page table CR3 has is unnecessary, isn't >>>>>>> it? >>>>>> >>>>>> The part is unnecessary if you use gdb. But it is necessary if you use crash. >>>>>> >>>>> >>>>> crash users would not use paging option because even if without using >>>>> it, we can see all memory well, so the paging option is only for gdb >>>>> users. >>>> >>>> Yes, the paging option is only for gdb users. The default value if off. >>>> >>>>> >>>>> It looks to me that the latter part only complicates the logic. If >>>>> instead, collecting virtual addresses only, way of handling PT_LOAD >>>>> entries become simpler, for example, they no longer need to be >>>>> physically contiguous in a single entry, and reviewing and maintaince >>>>> becomes easy. >>>> >>>> Sorry, I donot understand what do you want to say. >>>> >>> >>> The processing that adds part not referenced by page table to vmcore >>> is meaningless for gdb. crash doesn't require it. So, it only >>> complicates the current logic. >> >> If the paging mode is on, we can also use crash to analyze the vmcore. >> As the comment methioned, the memory used by the 1st kernel may be not >> referenced by the page table, so we neet this logic. >> > > As I said several times, crash users don't use paging mode. Users of > the paging mode is gdb only just as you say. So, the paging path needs > to collect part referenced by page table only since the other part is > invisible to gdb. If crash can work both with and without paging, it should be default *on* to avoid writing cores that can later on only be analyzed with that tool. Still not sure, though, if that changes the requirement on what memory regions should be written in that mode. Jan
At 03/09/2012 05:41 PM, Jan Kiszka Wrote: > On 2012-03-09 03:53, HATAYAMA Daisuke wrote: >> From: Wen Congyang <wency@cn.fujitsu.com> >> Subject: Re: [RFC][PATCH 05/16 v8] Add API to get memory mapping >> Date: Fri, 09 Mar 2012 10:26:56 +0800 >> >>> At 03/09/2012 10:05 AM, HATAYAMA Daisuke Wrote: >>>> From: Wen Congyang <wency@cn.fujitsu.com> >>>> Subject: Re: [RFC][PATCH 05/16 v8] Add API to get memory mapping >>>> Date: Fri, 09 Mar 2012 09:46:31 +0800 >>>> >>>>> At 03/09/2012 08:40 AM, HATAYAMA Daisuke Wrote: >>>>>> From: Wen Congyang <wency@cn.fujitsu.com> >>>>>> Subject: Re: [RFC][PATCH 05/16 v8] Add API to get memory mapping >>>>>> Date: Thu, 08 Mar 2012 16:52:29 +0800 >>>>>> >>>>>>> At 03/07/2012 11:27 PM, HATAYAMA Daisuke Wrote: >>>>>>>> From: Wen Congyang <wency@cn.fujitsu.com> >>>>>>>> Subject: [RFC][PATCH 05/16 v8] Add API to get memory mapping >>>>>>>> Date: Fri, 02 Mar 2012 18:18:23 +0800 >>>>>>>> >>>>>>>> >>>> >>>>>>>> How does the memory portion referenced by PT_LOAD program headers with >>>>>>>> p_vaddr == 0 looks through gdb? If we cannot access such portions, >>>>>>>> part not referenced by the page table CR3 has is unnecessary, isn't >>>>>>>> it? >>>>>>> >>>>>>> The part is unnecessary if you use gdb. But it is necessary if you use crash. >>>>>>> >>>>>> >>>>>> crash users would not use paging option because even if without using >>>>>> it, we can see all memory well, so the paging option is only for gdb >>>>>> users. >>>>> >>>>> Yes, the paging option is only for gdb users. The default value if off. >>>>> >>>>>> >>>>>> It looks to me that the latter part only complicates the logic. If >>>>>> instead, collecting virtual addresses only, way of handling PT_LOAD >>>>>> entries become simpler, for example, they no longer need to be >>>>>> physically contiguous in a single entry, and reviewing and maintaince >>>>>> becomes easy. >>>>> >>>>> Sorry, I donot understand what do you want to say. >>>>> >>>> >>>> The processing that adds part not referenced by page table to vmcore >>>> is meaningless for gdb. crash doesn't require it. So, it only >>>> complicates the current logic. >>> >>> If the paging mode is on, we can also use crash to analyze the vmcore. >>> As the comment methioned, the memory used by the 1st kernel may be not >>> referenced by the page table, so we neet this logic. >>> >> >> As I said several times, crash users don't use paging mode. Users of >> the paging mode is gdb only just as you say. So, the paging path needs >> to collect part referenced by page table only since the other part is >> invisible to gdb. > > If crash can work both with and without paging, it should be default > *on* to avoid writing cores that can later on only be analyzed with that > tool. Still not sure, though, if that changes the requirement on what > memory regions should be written in that mode. If this logic is not remvoed, crash can work both with and without paging. But the default value is 'off' now, because the option is '-p'. Thanks Wen Congyang > > Jan >
On 2012-03-09 10:57, Wen Congyang wrote: > At 03/09/2012 05:41 PM, Jan Kiszka Wrote: >> On 2012-03-09 03:53, HATAYAMA Daisuke wrote: >>> From: Wen Congyang <wency@cn.fujitsu.com> >>> Subject: Re: [RFC][PATCH 05/16 v8] Add API to get memory mapping >>> Date: Fri, 09 Mar 2012 10:26:56 +0800 >>> >>>> At 03/09/2012 10:05 AM, HATAYAMA Daisuke Wrote: >>>>> From: Wen Congyang <wency@cn.fujitsu.com> >>>>> Subject: Re: [RFC][PATCH 05/16 v8] Add API to get memory mapping >>>>> Date: Fri, 09 Mar 2012 09:46:31 +0800 >>>>> >>>>>> At 03/09/2012 08:40 AM, HATAYAMA Daisuke Wrote: >>>>>>> From: Wen Congyang <wency@cn.fujitsu.com> >>>>>>> Subject: Re: [RFC][PATCH 05/16 v8] Add API to get memory mapping >>>>>>> Date: Thu, 08 Mar 2012 16:52:29 +0800 >>>>>>> >>>>>>>> At 03/07/2012 11:27 PM, HATAYAMA Daisuke Wrote: >>>>>>>>> From: Wen Congyang <wency@cn.fujitsu.com> >>>>>>>>> Subject: [RFC][PATCH 05/16 v8] Add API to get memory mapping >>>>>>>>> Date: Fri, 02 Mar 2012 18:18:23 +0800 >>>>>>>>> >>>>>>>>> >>>>> >>>>>>>>> How does the memory portion referenced by PT_LOAD program headers with >>>>>>>>> p_vaddr == 0 looks through gdb? If we cannot access such portions, >>>>>>>>> part not referenced by the page table CR3 has is unnecessary, isn't >>>>>>>>> it? >>>>>>>> >>>>>>>> The part is unnecessary if you use gdb. But it is necessary if you use crash. >>>>>>>> >>>>>>> >>>>>>> crash users would not use paging option because even if without using >>>>>>> it, we can see all memory well, so the paging option is only for gdb >>>>>>> users. >>>>>> >>>>>> Yes, the paging option is only for gdb users. The default value if off. >>>>>> >>>>>>> >>>>>>> It looks to me that the latter part only complicates the logic. If >>>>>>> instead, collecting virtual addresses only, way of handling PT_LOAD >>>>>>> entries become simpler, for example, they no longer need to be >>>>>>> physically contiguous in a single entry, and reviewing and maintaince >>>>>>> becomes easy. >>>>>> >>>>>> Sorry, I donot understand what do you want to say. >>>>>> >>>>> >>>>> The processing that adds part not referenced by page table to vmcore >>>>> is meaningless for gdb. crash doesn't require it. So, it only >>>>> complicates the current logic. >>>> >>>> If the paging mode is on, we can also use crash to analyze the vmcore. >>>> As the comment methioned, the memory used by the 1st kernel may be not >>>> referenced by the page table, so we neet this logic. >>>> >>> >>> As I said several times, crash users don't use paging mode. Users of >>> the paging mode is gdb only just as you say. So, the paging path needs >>> to collect part referenced by page table only since the other part is >>> invisible to gdb. >> >> If crash can work both with and without paging, it should be default >> *on* to avoid writing cores that can later on only be analyzed with that >> tool. Still not sure, though, if that changes the requirement on what >> memory regions should be written in that mode. > > If this logic is not remvoed, crash can work both with and without paging. > But the default value is 'off' now, because the option is '-p'. And this would be unfortunate if you do not want to use crash for analyzing (I'm working on gdb python scripts which will make gdb - one day - at least as powerful as crash). If paging mode has the same information that non-paging mode has, I would even suggest to drop it. Jan
On 2012-03-09 11:05, Jan Kiszka wrote: >>> If crash can work both with and without paging, it should be default >>> *on* to avoid writing cores that can later on only be analyzed with that >>> tool. Still not sure, though, if that changes the requirement on what >>> memory regions should be written in that mode. >> >> If this logic is not remvoed, crash can work both with and without paging. >> But the default value is 'off' now, because the option is '-p'. > > And this would be unfortunate if you do not want to use crash for > analyzing (I'm working on gdb python scripts which will make gdb - one > day - at least as powerful as crash). If paging mode has the same > information that non-paging mode has, I would even suggest to drop it. Err, with "it" = "non-paging mode". Jan
From: Jan Kiszka <jan.kiszka@siemens.com> Subject: Re: [RFC][PATCH 05/16 v8] Add API to get memory mapping Date: Fri, 09 Mar 2012 11:06:30 +0100 > On 2012-03-09 11:05, Jan Kiszka wrote: >>>> If crash can work both with and without paging, it should be default >>>> *on* to avoid writing cores that can later on only be analyzed with that >>>> tool. Still not sure, though, if that changes the requirement on what >>>> memory regions should be written in that mode. >>> >>> If this logic is not remvoed, crash can work both with and without paging. >>> But the default value is 'off' now, because the option is '-p'. >> >> And this would be unfortunate if you do not want to use crash for >> analyzing (I'm working on gdb python scripts which will make gdb - one >> day - at least as powerful as crash). If paging mode has the same >> information that non-paging mode has, I would even suggest to drop it. > > Err, with "it" = "non-paging mode". > > Jan Paging at default is not good idea. Performing paging in qemu has risk. - Guest machine is not always in the state where paging mode is enabled. Also, CR3 doesn't always refer to page table. - If guest machine is in catastrophic state, its memory data could be corrupted. Then, we cannot trust such corrupted page table. # In this point, managing PT_LOAD program headers based on such # potencially corruppted data has risk. The idea of yours that performing paging in debugger side is better than doing in qemu. Thanks. HATAYAMA, Daisuke
On 2012-03-09 13:53, HATAYAMA Daisuke wrote: > From: Jan Kiszka <jan.kiszka@siemens.com> > Subject: Re: [RFC][PATCH 05/16 v8] Add API to get memory mapping > Date: Fri, 09 Mar 2012 11:06:30 +0100 > >> On 2012-03-09 11:05, Jan Kiszka wrote: >>>>> If crash can work both with and without paging, it should be default >>>>> *on* to avoid writing cores that can later on only be analyzed with that >>>>> tool. Still not sure, though, if that changes the requirement on what >>>>> memory regions should be written in that mode. >>>> >>>> If this logic is not remvoed, crash can work both with and without paging. >>>> But the default value is 'off' now, because the option is '-p'. >>> >>> And this would be unfortunate if you do not want to use crash for >>> analyzing (I'm working on gdb python scripts which will make gdb - one >>> day - at least as powerful as crash). If paging mode has the same >>> information that non-paging mode has, I would even suggest to drop it. >> >> Err, with "it" = "non-paging mode". >> >> Jan > > Paging at default is not good idea. Performing paging in qemu has risk. > > - Guest machine is not always in the state where paging mode is > enabled. Also, CR3 doesn't always refer to page table. That's detectable and means physical == linear address. > > - If guest machine is in catastrophic state, its memory data could > be corrupted. Then, we cannot trust such corrupted page table. OK, here I agree. > > # In this point, managing PT_LOAD program headers based on such > # potencially corruppted data has risk. > > The idea of yours that performing paging in debugger side is better > than doing in qemu. Another alternative is to add guest-awareness to the dump code. If we detect (or get told) that the target is a Linux kernel, at least the linear kernel mapping can be written reliably. But also the fact that there can be as many different page tables as active processors means that paging likely needs a second thought and more awareness of the debugger. Jan
At 03/09/2012 06:05 PM, Jan Kiszka Wrote: > On 2012-03-09 10:57, Wen Congyang wrote: >> At 03/09/2012 05:41 PM, Jan Kiszka Wrote: >>> On 2012-03-09 03:53, HATAYAMA Daisuke wrote: >>>> From: Wen Congyang <wency@cn.fujitsu.com> >>>> Subject: Re: [RFC][PATCH 05/16 v8] Add API to get memory mapping >>>> Date: Fri, 09 Mar 2012 10:26:56 +0800 >>>> >>>>> At 03/09/2012 10:05 AM, HATAYAMA Daisuke Wrote: >>>>>> From: Wen Congyang <wency@cn.fujitsu.com> >>>>>> Subject: Re: [RFC][PATCH 05/16 v8] Add API to get memory mapping >>>>>> Date: Fri, 09 Mar 2012 09:46:31 +0800 >>>>>> >>>>>>> At 03/09/2012 08:40 AM, HATAYAMA Daisuke Wrote: >>>>>>>> From: Wen Congyang <wency@cn.fujitsu.com> >>>>>>>> Subject: Re: [RFC][PATCH 05/16 v8] Add API to get memory mapping >>>>>>>> Date: Thu, 08 Mar 2012 16:52:29 +0800 >>>>>>>> >>>>>>>>> At 03/07/2012 11:27 PM, HATAYAMA Daisuke Wrote: >>>>>>>>>> From: Wen Congyang <wency@cn.fujitsu.com> >>>>>>>>>> Subject: [RFC][PATCH 05/16 v8] Add API to get memory mapping >>>>>>>>>> Date: Fri, 02 Mar 2012 18:18:23 +0800 >>>>>>>>>> >>>>>>>>>> >>>>>> >>>>>>>>>> How does the memory portion referenced by PT_LOAD program headers with >>>>>>>>>> p_vaddr == 0 looks through gdb? If we cannot access such portions, >>>>>>>>>> part not referenced by the page table CR3 has is unnecessary, isn't >>>>>>>>>> it? >>>>>>>>> >>>>>>>>> The part is unnecessary if you use gdb. But it is necessary if you use crash. >>>>>>>>> >>>>>>>> >>>>>>>> crash users would not use paging option because even if without using >>>>>>>> it, we can see all memory well, so the paging option is only for gdb >>>>>>>> users. >>>>>>> >>>>>>> Yes, the paging option is only for gdb users. The default value if off. >>>>>>> >>>>>>>> >>>>>>>> It looks to me that the latter part only complicates the logic. If >>>>>>>> instead, collecting virtual addresses only, way of handling PT_LOAD >>>>>>>> entries become simpler, for example, they no longer need to be >>>>>>>> physically contiguous in a single entry, and reviewing and maintaince >>>>>>>> becomes easy. >>>>>>> >>>>>>> Sorry, I donot understand what do you want to say. >>>>>>> >>>>>> >>>>>> The processing that adds part not referenced by page table to vmcore >>>>>> is meaningless for gdb. crash doesn't require it. So, it only >>>>>> complicates the current logic. >>>>> >>>>> If the paging mode is on, we can also use crash to analyze the vmcore. >>>>> As the comment methioned, the memory used by the 1st kernel may be not >>>>> referenced by the page table, so we neet this logic. >>>>> >>>> >>>> As I said several times, crash users don't use paging mode. Users of >>>> the paging mode is gdb only just as you say. So, the paging path needs >>>> to collect part referenced by page table only since the other part is >>>> invisible to gdb. >>> >>> If crash can work both with and without paging, it should be default >>> *on* to avoid writing cores that can later on only be analyzed with that >>> tool. Still not sure, though, if that changes the requirement on what >>> memory regions should be written in that mode. >> >> If this logic is not remvoed, crash can work both with and without paging. >> But the default value is 'off' now, because the option is '-p'. > > And this would be unfortunate if you do not want to use crash for > analyzing (I'm working on gdb python scripts which will make gdb - one > day - at least as powerful as crash). If paging mode has the same > information that non-paging mode has, I would even suggest to drop it. I donot have any knowledge about gdb python scripts. But is it OK to work without virtual address in PT_LOAD? Thanks Wen Congyang > > Jan >
From: Jan Kiszka <jan.kiszka@siemens.com> Subject: Re: [RFC][PATCH 05/16 v8] Add API to get memory mapping Date: Fri, 09 Mar 2012 14:24:41 +0100 > On 2012-03-09 13:53, HATAYAMA Daisuke wrote: >> From: Jan Kiszka <jan.kiszka@siemens.com> >> Subject: Re: [RFC][PATCH 05/16 v8] Add API to get memory mapping >> Date: Fri, 09 Mar 2012 11:06:30 +0100 >> >>> On 2012-03-09 11:05, Jan Kiszka wrote: >>>>>> If crash can work both with and without paging, it should be default >>>>>> *on* to avoid writing cores that can later on only be analyzed with that >>>>>> tool. Still not sure, though, if that changes the requirement on what >>>>>> memory regions should be written in that mode. >>>>> >>>>> If this logic is not remvoed, crash can work both with and without paging. >>>>> But the default value is 'off' now, because the option is '-p'. >>>> >>>> And this would be unfortunate if you do not want to use crash for >>>> analyzing (I'm working on gdb python scripts which will make gdb - one >>>> day - at least as powerful as crash). If paging mode has the same >>>> information that non-paging mode has, I would even suggest to drop it. >>> >>> Err, with "it" = "non-paging mode". >>> >>> Jan >> >> Paging at default is not good idea. Performing paging in qemu has risk. >> >> - Guest machine is not always in the state where paging mode is >> enabled. Also, CR3 doesn't always refer to page table. > > That's detectable and means physical == linear address. > CR0 itself is one of the guest's resources. There's still the issue whether to trust CR0 or not. The assumption behind my idea is the host is running in a good condition but the quest in a bad condition. So we can use qemu dump, which is the host's feature. Only checking if CR3 refers to page table correctly is considerably complicated. CR3 can have any physical address. There's no hint such as magic number to check it's invalid. So, to check if CR3 correctly points at page table, the only way is to check if we can see the data through actually performing paging for some virtual address. The virtual address would be better if it's more typical one, but it tends to be guest specific, and I think it's not suitable for qemu due to OS dependency. # Of course, this story is done out of the assumption that the data # could be corrupted. >> >> - If guest machine is in catastrophic state, its memory data could >> be corrupted. Then, we cannot trust such corrupted page table. > > OK, here I agree. > >> >> # In this point, managing PT_LOAD program headers based on such >> # potencially corruppted data has risk. >> >> The idea of yours that performing paging in debugger side is better >> than doing in qemu. > > Another alternative is to add guest-awareness to the dump code. If we > detect (or get told) that the target is a Linux kernel, at least the > linear kernel mapping can be written reliably. > > But also the fact that there can be as many different page tables as > active processors means that paging likely needs a second thought and > more awareness of the debugger. Also, it seems to me that the lacking feature of gdb used to dumpfile compared with used to running guest is paging only. Paging is a feature in architecture, which is unlikely to change in the future. It's better in maintainability than introducing OS-level dependency. Thanks. HATAYAMA, Daisuke
From: HATAYAMA Daisuke <d.hatayama@jp.fujitsu.com> Subject: Re: [Qemu-devel] [RFC][PATCH 05/16 v8] Add API to get memory mapping Date: Mon, 12 Mar 2012 15:16:55 +0900 ( ) > > The assumption behind my idea is the host is running in a good > condition but the quest in a bad condition. So we can use qemu dump, > which is the host's feature. There's also the situation that a guest is running in a good condition and users can recognize that its data is obviously not corrupted. For such situation, it's natural for qemu dump to have paging mode to some amount. Thanks. HATAYAMA, Daisuke
diff --git a/memory_mapping.c b/memory_mapping.c index 718f271..f74c5d0 100644 --- a/memory_mapping.c +++ b/memory_mapping.c @@ -164,3 +164,91 @@ void memory_mapping_list_init(MemoryMappingList *list) list->last_mapping = NULL; QTAILQ_INIT(&list->head); } + +int qemu_get_guest_memory_mapping(MemoryMappingList *list) +{ + CPUState *env; + MemoryMapping *memory_mapping; + RAMBlock *block; + ram_addr_t offset, length, m_length; + target_phys_addr_t m_phys_addr; + int ret; + bool paging_mode; + +#if defined(CONFIG_HAVE_GET_MEMORY_MAPPING) + paging_mode = cpu_paging_enabled(first_cpu); + if (paging_mode) { + for (env = first_cpu; env != NULL; env = env->next_cpu) { + ret = cpu_get_memory_mapping(list, env); + if (ret < 0) { + return -1; + } + } + } +#else + return -2; +#endif + + /* + * some memory may be not in the memory mapping's list: + * 1. the guest doesn't use paging + * 2. the guest is in 2nd kernel, and the memory used by 1st kernel is not + * in paging table + * add them into memory mapping's list + */ + QLIST_FOREACH(block, &ram_list.blocks, next) { + offset = block->offset; + length = block->length; + + if (!paging_mode) { + create_new_memory_mapping(list, offset, offset, length); + continue; + } + + QTAILQ_FOREACH(memory_mapping, &list->head, next) { + m_phys_addr = memory_mapping->phys_addr; + m_length = memory_mapping->length; + + if (offset + length <= m_phys_addr) { + /* + * memory_mapping's list does not conatin the region + * [offset, offset+length) + */ + create_new_memory_mapping(list, offset, 0, length); + length = 0; + break; + } + + if (m_phys_addr + m_length <= offset) { + continue; + } + + if (m_phys_addr > offset) { + /* + * memory_mapping's list does not conatin the region + * [offset, memory_mapping->phys_addr) + */ + create_new_memory_mapping(list, offset, 0, + m_phys_addr - offset); + } + + if (offset + length <= m_phys_addr + m_length) { + length = 0; + break; + } + + length -= m_phys_addr + m_length - offset; + offset = m_phys_addr + m_length; + } + + if (length > 0) { + /* + * memory_mapping's list does not conatin the region + * [offset, memory_mapping->phys_addr) + */ + create_new_memory_mapping(list, offset, 0, length); + } + } + + return 0; +} diff --git a/memory_mapping.h b/memory_mapping.h index 836b047..ebd7cf6 100644 --- a/memory_mapping.h +++ b/memory_mapping.h @@ -44,4 +44,12 @@ void memory_mapping_list_free(MemoryMappingList *list); void memory_mapping_list_init(MemoryMappingList *list); +/* + * Return value: + * 0: success + * -1: failed + * -2: unsupported + */ +int qemu_get_guest_memory_mapping(MemoryMappingList *list); + #endif
Add API to get all virtual address and physical address mapping. If there is no virtual address for some physical address, the virtual address is 0. Signed-off-by: Wen Congyang <wency@cn.fujitsu.com> --- memory_mapping.c | 88 ++++++++++++++++++++++++++++++++++++++++++++++++++++++ memory_mapping.h | 8 +++++ 2 files changed, 96 insertions(+), 0 deletions(-)