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).
Thanks :) Cheers, -- Jean-Yves Migeon jean-yves.migeon%espci.fr@localhost