From: Wen Congyang <we...@cn.fujitsu.com>
Subject: Re: [RFC][PATCH 03/14 v7] target-i386: implement
cpu_get_memory_mapping()
Date: Thu, 01 Mar 2012 14:21:37 +0800
> At 03/01/2012 02:13 PM, HATAYAMA Daisuke Wrote:
>> From: Wen Congyang <we...@cn.fujitsu.com>
>> Subject: [RFC][PATCH 03/14 v7] target-i386: implement
>> cpu_get_memory_mapping()
>> Date: Thu, 01 Mar 2012 10:41:47 +0800
>>
>>> +int cpu_get_memory_mapping(MemoryMappingList *list, CPUState *env)
>>> +{
>>> + if (env->cr[4] & CR4_PAE_MASK) {
>>> +#ifdef TARGET_X86_64
>>> + if (env->hflags & HF_LMA_MASK) {
>>> + target_phys_addr_t pml4e_addr;
>>> +
>>> + pml4e_addr = (env->cr[3] & ~0xfff) & env->a20_mask;
>>> + walk_pml4e(list, pml4e_addr, env->a20_mask);
>>> + } else
>>> +#endif
>>> + {
>>> + target_phys_addr_t pdpe_addr;
>>> +
>>> + pdpe_addr = (env->cr[3] & ~0x1f) & env->a20_mask;
>>> + walk_pdpe2(list, pdpe_addr, env->a20_mask);
>>> + }
>>> + } else {
>>> + target_phys_addr_t pde_addr;
>>> + bool pse;
>>> +
>>> + pde_addr = (env->cr[3] & ~0xfff) & env->a20_mask;
>>> + pse = !!(env->cr[4] & CR4_PSE_MASK);
>>> + walk_pde2(list, pde_addr, env->a20_mask, pse);
>>> + }
>>> +
>>> + return 0;
>>> +}
>>
>> Does this assume paging mode? I don't know qemu very well, but qemu
>> dump command runs externally to guest machine, so I think the machine
>> could be in the state with paging disabled where CR4 doesn't refer to
>> page table as expected.
>
> CR4? I think you want to say CR3.
>
> Yes, the guest may be in the state without paging mode. I will fix it.
>
Hmmm, now I think dump command needs to have a option to specify
whether to do paging or not during dumping. Doing always paging is
problematic. Also generated formats should be as simple as possible,
different from the format this current version generates. The reasons
I have are as follows:
- The qemu dump command runs outside of guest machine. If machine is
in the state with paging disabled and CR3 doesn't has page table
address, qemu dump command cannot do paging.
- We cannot do paging if guest machine state is severe. For example,
when page table data is corrupted in some reason. In general, we
should use minimum kinds of data only during dumping.
- There's also kdump specific issue. On kdump there are two kinds of
kernels, 1st kernel and 2nd kernel, and when crash happens,
execution is transmitted from the 1st to the 2nd, and then the 2nd
kernel copies the 1st kernel's kernel image. The problem is that
at catastrophic situation, kdump can also hang even in the 2nd
kernel. At this point, the 2nd kernel refers to the 2nd kernel's
page table. So paging at the situation leads to lost of the 1st
kernel's memory.
- OTOH, gdb cannot perform paging, so, for gdb support, qemu dump
needs to have paging mode. The period when qemu dump can produce
the dump gdb can read is limited to the machine state with paging
enabled and the 1st krenel, but I think no choise.
* There's a way of getting the 1st kernel's image as linear image
from the dumpfile generated at the 2nd kernel generated without
paging. But it uses kenrel's specific information, so I don't
think qemu should do this.
- Well, it's possible to generate dumpfile while enabling both
physical and linear address access together. It's just what Wen is
doing now. But I think it better to do that more simply: that is,
if non-paging mode, produce dumpfile as raw format; if paging
mode, produce as linear format.
* For example, the current implementation assigns both virtual and
physical address to a single PT_LOAD entry. But the memory areas
mapped to by a single PT_LOAD is restricted to the ones
contiguous both physically and virtually. Due to this, I guess
there's a case where the number of program headers grows
seriously in the worst case. It might reach ELF's limit size.
* Also, by this, it's necessary to reduce the number of program
headers as much as possible, and now qemu dump tries to merge
them in PATCH 01, but it looks to me too complicated.
How do other people think?
Thanks.
HATAYAMA, Daisuke
