On 2016/7/14 21:19, Eric W. Biederman wrote: > zhong jiang <[email protected]> writes: > >> On 2016/7/12 23:46, Eric W. Biederman wrote: >>> zhongjiang <[email protected]> writes: >>> >>>> From: zhong jiang <[email protected]> >>>> >>>> when image is loaded into kernel, we need set up page table for it. and >>>> all valid pfn also set up new mapping. it will tend to establish a pmd >>>> page table in the form of a large page if pud_present is true. >>>> relocate_kernel >>>> points to code segment can locate in the pmd huge entry in >>>> init_transtion_pgtable. >>>> therefore, we need to take the situation into account. >>> I can see how in theory this might be necessary but when is a kernel virtual >>> address on x86_64 that is above 0x8000000000000000 in conflict with an >>> identity mapped physicall address that are all below 0x8000000000000000? >>> >>> If anything the code could be simplified to always assume those mappings >>> are unoccupied. >>> >>> Did you run into an actual failure somewhere? >>> >>> Eric >>> >> I do not understand what you trying to say, Maybe I miss your point. >> >> The key is how to ensure that relocate_kernel points to the pmd >> entry is not huge page. > Kernel virtual addresses are in the negative half of the address space. > Identity mapped physical addresses are in the positive half of the > address space. > > As the entire negative half of the address space at the time that page > table entry is being created the are no huge pages present. > > Even testing pmd_present is a redundant, and that is probably the bug. > > Eric > > . ok , I know your mean. we allocate new pgd page, that is control_code_page, to rebuild new mapping machanism in init_pgtable. because the relocate_kernel is in the negative half of the address space. and The page table is not establise for the new pgd. To my surprise, if the page table is not exist, why we need check p(g,u,m)d_present() . if not , I still think that it can exist a pmd huge .
or Maybe I misunderstand its meaning. Thanks zhongjiang _______________________________________________ kexec mailing list [email protected] http://lists.infradead.org/mailman/listinfo/kexec
