All of lore.kernel.org
 help / color / mirror / Atom feed
From: Wen Congyang <wency@cn.fujitsu.com>
To: HATAYAMA Daisuke <d.hatayama@jp.fujitsu.com>
Cc: aliguori@us.ibm.com, jan.kiszka@siemens.com,
	qemu-devel@nongnu.org, lcapitulino@redhat.com,
	anderson@redhat.com, eblake@redhat.com
Subject: Re: [Qemu-devel] [PATCH 05/11 v10] Add API to get memory mapping
Date: Mon, 26 Mar 2012 09:10:52 +0800	[thread overview]
Message-ID: <4F6FC21C.3070002@cn.fujitsu.com> (raw)
In-Reply-To: <20120323.210202.434298361.d.hatayama@jp.fujitsu.com>

At 03/23/2012 08:02 PM, HATAYAMA Daisuke Wrote:
> From: Wen Congyang <wency@cn.fujitsu.com>
> Subject: [PATCH 05/11 v10] Add API to get memory mapping
> Date: Tue, 20 Mar 2012 11:51:18 +0800
> 
>> Add API to get all virtual address and physical address mapping.
>> If the guest doesn't use paging, the virtual address is equal to the phyical
>> address. The virtual address and physical address mapping is for gdb's user, and
>> it does not include the memory that is not referenced by the page table. So if
>> you want to use crash to anaylze the vmcore, please do not specify -p option.
>> the reason why the -p option is not default explicitly: guest machine in a
>> catastrophic state can have corrupted memory, which we cannot trust.
>>
>> Signed-off-by: Wen Congyang <wency@cn.fujitsu.com>
>> ---
>>  memory_mapping.c |   34 ++++++++++++++++++++++++++++++++++
>>  memory_mapping.h |   15 +++++++++++++++
>>  2 files changed, 49 insertions(+), 0 deletions(-)
>>
>> diff --git a/memory_mapping.c b/memory_mapping.c
>> index 718f271..b92e2f6 100644
>> --- a/memory_mapping.c
>> +++ b/memory_mapping.c
>> @@ -164,3 +164,37 @@ void memory_mapping_list_init(MemoryMappingList *list)
>>      list->last_mapping = NULL;
>>      QTAILQ_INIT(&list->head);
>>  }
>> +
>> +#if defined(CONFIG_HAVE_GET_MEMORY_MAPPING)
>> +int qemu_get_guest_memory_mapping(MemoryMappingList *list)
>> +{
>> +    CPUArchState *env;
>> +    RAMBlock *block;
>> +    ram_addr_t offset, length;
>> +    int ret;
>> +    bool paging_mode;
>> +
>> +    paging_mode = cpu_paging_enabled(first_cpu);
>> +    if (paging_mode) {
> 
> On SMP with (n)-CPUs, we can do this check at most (n)-times.
> 
> On Linux, user-mode tasks have differnet page tables. If refering to
> one page table, we can get one user-mode task memory only. Considering
> as much memory as possible, it's best to reference all CPUs with
> paging enabled and walk all the page tables.
> 
> A problem is that linear addresses for user-mode tasks can inherently
> conflicts. Different user-mode tasks can have the same linear
> address. So, tools need to distinguish each PT_LOAD entry based on a
> pair of linear address and physical address, not linear address
> only. I don't know whether gdb does this.

gdb only can process kernel space. Jan's gdb-python script may can process
user-mode tasks, but we should get user-mode task's register from the kernel
or note, and convest virtual address/linear address to physicall address.

> 
>> +        for (env = first_cpu; env != NULL; env = env->next_cpu) {
>> +            ret = cpu_get_memory_mapping(list, env);
>> +            if (ret < 0) {
>> +                return -1;
>> +            }
>> +        }
>> +        return 0;
>> +    }
>> +
>> +    /*
>> +     * If the guest doesn't use paging, the virtual address is equal to physical
>> +     * address.
>> +     */
> 
> IIRC, ACPI sleep state goes in real-mode. There might be another that
> can go in real-mode. If execution enters this path in such situation,
> linear addresses are meaningless. But this is really rare case.

I donot meet such case, and I donot know what should I do in this patch now.
So I donot change it now.

Thanks
Wen Congyang

> 
>> +    QLIST_FOREACH(block, &ram_list.blocks, next) {
>> +        offset = block->offset;
>> +        length = block->length;
>> +        create_new_memory_mapping(list, offset, offset, length);
>> +    }
>> +
>> +    return 0;
>> +}
> 
> Thanks.
> HATAYAMA, Daisuke
> 
> 

  reply	other threads:[~2012-03-26  1:08 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-03-20  3:51 [Qemu-devel] [PATCH 05/11 v10] Add API to get memory mapping Wen Congyang
2012-03-23 12:02 ` HATAYAMA Daisuke
2012-03-26  1:10   ` Wen Congyang [this message]
2012-03-26  2:31     ` HATAYAMA Daisuke
2012-03-26  2:44       ` Wen Congyang
2012-03-27  1:01         ` HATAYAMA Daisuke
2012-03-27  1:25           ` Wen Congyang

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4F6FC21C.3070002@cn.fujitsu.com \
    --to=wency@cn.fujitsu.com \
    --cc=aliguori@us.ibm.com \
    --cc=anderson@redhat.com \
    --cc=d.hatayama@jp.fujitsu.com \
    --cc=eblake@redhat.com \
    --cc=jan.kiszka@siemens.com \
    --cc=lcapitulino@redhat.com \
    --cc=qemu-devel@nongnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.