[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: [suspend/resume] memory_op hypercall failure: XENMEM_maximum_gpfn
Manuel Bouyer wrote:
Actually, it is a "simple" 3-layered p2m table. A bit different than the
xpmap_phys_to_machine_mapping used in NetBSD, but not really much.
It unfortunate that it has a different format than xen_start_info.mfn_list.
We need to build it then, I guess. Fortunably, it shouldn't change beyond
boot or suspend/resume.
For i386, we got 3 layers of mfn elements, each referencing another
level (it resembles PAE, where we have PDP table => PD table => PT).
Building it with xpmap_phys_to_machine_mapping indexes will be ok, and
it will avoid simultaneously all the "tricks" to keep both table in sync.
However, the implementation is weird, the 32 bit long used as pfn is cut
in 3 parts of 10 bits (10+10+10, 2 bits unused?), each part being the
offset in the corresponding layer. It's definitely different from PAE
with its 2+9+9+12 or non PAE with 10+10+12 model.
From my PoV, that is the scheme adopted for i386, PAE or non PAE. For
amd64, I am left with Linux code. I would expect that the p2m table
changes, as it is arch specific. I will give it a try tomorrow.
Since I am using xpmap_phys_to_machine_mapping to build it, is it ok to
put the "arch.pfn_to_mfn_frame_list_list" initialization in
pmap_bootstrap code? Not too early in boot process?
I just did change it to make it compile. As you can see I use the same
rounding as on linux, and I'm not sure why it wouldn't work here (mlock()
is supposed to be standard).
Main Index |
Thread Index |