Re: p2m stuff and crash tool

[Daniel Kiper]

On Tue, Feb 16, 2016 at 01:55:33PM +0100, Juergen Gross wrote:
> Hi Daniel,
>
> On 16/02/16 12:35, Daniel Kiper wrote:
> > Hey Juergen,

[...]

> > After that I decided to take a look at Linux kernel upstream. I saw
> > that xen_max_p2m_pfn in xen_build_mfn_list_list() is equal to "the
> > end of last usable machine memory region available for a given
> > dom0_mem argument + something", e.g.
> >
> > For dom0_mem=1g,max:1g:
> >
> > (XEN) Xen-e820 RAM map:
> > (XEN)  0000000000000000 - 000000000009fc00 (usable)
> > (XEN)  000000000009fc00 - 00000000000a0000 (reserved)
> > (XEN)  00000000000f0000 - 0000000000100000 (reserved)
> > (XEN)  0000000000100000 - 000000007ffdf000 (usable)   <--- HERE
> > (XEN)  000000007ffdf000 - 0000000080000000 (reserved)
> > (XEN)  00000000b0000000 - 00000000c0000000 (reserved)
> > (XEN)  00000000feffc000 - 00000000ff000000 (reserved)
> > (XEN)  00000000fffc0000 - 0000000100000000 (reserved)
> > (XEN)  0000000100000000 - 0000000180000000 (usable)
> >
> > Hence xen_max_p2m_pfn == 0x80000
> >
> > Later I reviewed most of your p2m related commits and I realized
> > that you played whack-a-mole game with p2m bugs. Sadly, I was not
> > able to identify exactly one (or more) commit which would fix the
> > same issue (well, there are some which fixes similar stuff but not
> > the same one described above). So, if you explain to me why
> > xen_max_p2m_pfn is set to that value and does not e.g. max_pfn then
> > it will be much easier for me to write proper fix and maybe fix
> > the same issue in upstream kernel if it is needed (well, crash
> > tool does not work with new p2m layout so first of all I must fix it;
> > I hope that you will help me to that sooner or later).
>
> The reason for setting xen_max_p2m_pfn to nr_pages initially is it's
> usage in __pfn_to_mfn(): this must work with the initial p2m list
> supplied by the hypervisor which just has only nr_pages entries.

That make sense.

> Later it is updated to the number of entries the linear p2m list is
> able to hold. This size has to include possible hotplugged memory
> in prder to be able to make use of that memory later (remember: the
> p2m list's size is limited by the virtual space allocated for it via
> xen_vmalloc_p2m_tree()).

However, I have memory hotplug disabled and kernel set xen_max_p2m_pfn
to 0x80000 (2 Gib) even if dom0 memory was set to 1 GiB. Hmmm... Why?
I suppose that if xen_max_p2m_pfn == max_pfn then everything should work.
Am I missing something?

Daniel