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
memory.
>
>
>>1) Am I missing something here? Is there some sort of initialization of the
>>machine_to_phys_mapping
>>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 :).
Thanks,
Chris Lalancette
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home