[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Xen-devel] Tracking "Cannot allocate memory" error in shadow_alloc_p2m_table



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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.