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

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

Tim Deegan wrote:
> Hi,
> At 16:16 -0500 on 09 Jan (1168359405), Chris Lalancette wrote:
>>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.
> Are you giving this domain more than 7GB of RAM on a PAE hypervisor?

Yes, the Hypervisor is i686 PAE, but no, the FV domain that I am trying to 
start up only has 512MB of

>>1)  Am I missing something here?  Is there some sort of initialization of the 
>>table that I missed?
> The code you cut out is start-of-day code that builds the p2m map of a
> domain from the m2p entries of its allocated pages.  It was needed
> originally because the domain builder tools would set up the guest's
> memory and m2p mapping and _then_ enable shadow-translate mode.  It may
> not be necessary now that HVM domains are put in shadow mode at creation
> time.
> AFAICS, either the domain should have no memory assigned yet (in which
> case it does nothing), or the domain's pages should have m2p entries
> that are valid, explicitly invalid, or set to the "debug pattern" of all
> 5s.  I'll look at a more sensible failure mode then -ENOMEM, though.

Ah, that makes sense.  Yeah, I was thinking that the other way to solve this 
was to initialize the whole
machine_to_phys_mapping table to something sensible, but then I just didn't 
even see why it needed to be
done at this early stage, so I took the code out.  Either way is fine with 
me...I would just like to see
the FV domains start working on this large memory machine :).

Chris Lalancette

Xen-devel mailing list



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