Hello,
I've been working on tracking down a "Cannot allocate memory" error when
trying to start FV domains.
I finally found a 16GB box where I could reliably reproduce the problem. By
turning on trace debugging and adding a few of my own prints, I was able to see
that the error came from this code path:
shadow_alloc_p2m_table() -> shadow_set_p2m_entry -> p2m_next_level ->
p2m_find_entry
(all in arch/x86/mm/shadow/common.c). What's happening is that the
gfn_remainder passed into
p2m_find_entry is something like 0x3a3815 which, when shifted by shift (which
would happen to be 18 in
the case of the 3rd-level page table in i686 PAE), it would end up being larger
than the max (which is 8),
and hence causing the failure. Looking deeper into it, there is something I
really don't understand,
though. shadow_alloc_p2m_table fetches each page in the page_list, then gets
the page struct, then
converts to mfn using page_to_mfn, and finally gets the gfn using
get_gpfn_from_mfn. get_gpfn_from_mfn
is defined in include/asm-x86/mm.h, and looks to be just pulling the mfn ->
gpfn mapping out of the
machine_to_phys_mapping table. The problem, as I see it, is that no one ever
put a valid entry into
machine_to_phys_mapping, so the data returned there is bogus. Once I commented
out this section of code
in shadow_alloc_p2m_table():
/*
for ( entry = d->page_list.next;
entry != &d->page_list;
entry = entry->next )
{
page = list_entry(entry, struct page_info, list);
mfn = page_to_mfn(page);
gfn = get_gpfn_from_mfn(mfn_x(mfn));
page_count++;
if (
#ifdef __x86_64__
(gfn != 0x5555555555555555L)
#else
(gfn != 0x55555555L)
#endif
&& gfn != INVALID_M2P_ENTRY
&& !shadow_set_p2m_entry(d, gfn, mfn) )
goto error;
}
*/
I was able to successfully start some FV domains.
1) Am I missing something here? Is there some sort of initialization of the
machine_to_phys_mapping
table that I missed?
2) Why do we need the above code during the creation of a new domain? I would
think there aren't any
valid pages in the page_list we would have to worry about at that point.
Of course, I am by no means a shadow table expert, so I'm sure I'm missing
something. Any ideas?
Thanks,
Chris Lalancette
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home