RE: [Xen-devel] x86-64's contig_initmem_init

["Nakajima, Jun" <jun.nakajima@xxxxxxxxx>]

Jan Beulich wrote:
>> The tail part of the initial mapping has no special handling on i386
>> nor on x86_64. It just gets freed up when we free from 0 up to
>> max_pfn, and it never gets reserved (the reserved region precisely
>> covers kernel text/data and initial page tables).
> 
> For i386 I'm not certain, but for x86-64 I doubt that:
> init_memory_mapping, which runs before contig_initmem_init,
> re-initializes start_pfn (which is what in turn gets used to set up
> the bootmem reservation) from the result of scanning the initial page
> tables. These, as I understand it, extend to the 4-Mb-rounded end of
> the initial mapping (which, if the unused tail turns out to be less
> than 512k, even gets extended by an extra 4M).
> 

Okay, I wrote the code originally. It's extended to access all the pge,
pud, pmd, pte pages when establishing 1:1 direct mapping against the
guest physical memory. Unlike the native x86_64 linux, the current
x86_64 xenlinux cannot use 2MB, so we need to allocate a lot of (extra)
L1 pages if the guest memory is large. For those page table pages, I set
RO at contig_initmem_init. 

I don't think it's 4-Mb-rounded, but I'll take a look at the code.

BTW, when do/did you start seeing the problme?


>> Actually, that could be another bug on x86/64 -- I may need to
>> truncate the initial mapping, or we may be ending up with spurious
>> extra writable mappings to some pages... I'll take a look and see if
>> this is 
> 
>> the case.
> 
> If the above wasn't true (or was fixed), then I'd assume such a bug
> would surface (and again I'm not sure why i386 wouldn't surface it,
> as I can't see where these mappings get torn down).
> 
> Jan
> 

Jun
---
Intel Open Source Technology Center

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel