Hi, Xen experts, We are doing some development with xen-3.3.0 . We plan to use Mini-OS as a trusted computing base and boot it in the first place. We have removed all Xenstore/Console reference in Mini-OS, since there will not be Xenstore or console at that time. And we moved its virtual address base to 0xc0000000 Then something strange happened within /* init_mm() */ . I specified /* dom0_mem=32M */ , and got following message. Xen Minimal OS! start_info: c1062000 nr_pages: 8192 shared_inf: 001e9000 pt_base: c1063000 mod_start: 0xc004a000 mod_len: 16842752 flags: 0x3 cmd_line: stack: c0029460-c0049460 MM: Init _text: c0000000 _etext: c001a104 _erodata: c001f000 _edata: c001f2f0 stack start: c0029460 _end: c0049910 start_pfn: 1075 max_pfn: 2000 Mapping memory range 0xc1800000 - 0xc2000000 setting c0000000-c001f000 readonly skipped c0001000 MM: Initialise page allocator for c1079000(1079000)-0(c2000000) Page fault at linear address c1400008, eip c000ceee, regs c003ff08, sp 0000107a, our_sp c003fef0, code 2 Page fault in pagetable walk (access to invalid memory?). Notice the 3rd line to the last, "Initialise page allocator for c1079000(1079000)-0(c2000000)". According to source code, last physical address of that line should be 2000000, not c2000000, and corresponding virtual address should be c2000000, not 0. How could this possibly go wrong? I am confused. There is another problem with page fault. The 2nd line to the last, PF at linear address c1400008. I thought that VA should have been mapped correctly, because /* build_pagetable() */ didn''t complain anything. I checked /* physical_to_machine */ array, found a mapping between that VA and machine frame. By the way, if I use this Mini-OS image as a domU, it should boot up properly. Does anybody know any thing about those issues? I''m looking forward to your reply. Thanks in advanced. LIU Wei _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
LIU Wei, le Tue 27 Oct 2009 21:18:34 +0800, a écrit :> max_pfn: 2000 > MM: Initialise page allocator for c1079000(1079000)-0(c2000000)> According to source code, last physical address of that line should > be 2000000, not c2000000, and corresponding virtual address should be > c2000000, not 0. How could this possibly go wrong? I am confused.I am too. Have you somehow modified arch/x86/mm.c? Samuel _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
2009/10/27 Samuel Thibault <samuel.thibault@ens-lyon.org>:> LIU Wei, le Tue 27 Oct 2009 21:18:34 +0800, a écrit : >> max_pfn: 2000 >> MM: Initialise page allocator for c1079000(1079000)-0(c2000000) > >> According to source code, last physical address of that line should >> be 2000000, not c2000000, and corresponding virtual address should be >> c2000000, not 0. How could this possibly go wrong? I am confused. > > I am too. Have you somehow modified arch/x86/mm.c? > > Samuel >Not yet. I just added some debugging output to help my development. I''m still working on Mini-OS management module, which is making few progress. Another strange thing is, though we get a wrong caculation result here, subsequent cauculations work fine. That means we initialize MM with proper arguments, which is proved by my trace in /* build_pagetable() */. I''m doing development with VMWare, because I don''t have another machine to communicate with XEN through a serial port. I don''t know if this will cause any side effect. I''m wondering if you can offer any advise, I''ll be happy to hear that. Regards LIU Wei _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
LIU Wei, le Tue 27 Oct 2009 23:29:16 +0800, a écrit :> 2009/10/27 Samuel Thibault <samuel.thibault@ens-lyon.org>: > > LIU Wei, le Tue 27 Oct 2009 21:18:34 +0800, a écrit : > >> max_pfn: 2000 > >> MM: Initialise page allocator for c1079000(1079000)-0(c2000000) > > > >> According to source code, last physical address of that line should > >> be 2000000, not c2000000, and corresponding virtual address should be > >> c2000000, not 0. How could this possibly go wrong? I am confused. > > > > I am too. Have you somehow modified arch/x86/mm.c? > > Not yet. I just added some debugging output to help my development. > I''m still working on Mini-OS management module, which is making few > progress. > > Another strange thing is, though we get a wrong caculation result here,Mmm, please try to cast the result of PFN_PHYS into (u_long), as the format is %lx, not suitable for uint64_t returned by PFN_PHYS. Samuel _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
2009/10/27 Samuel Thibault <samuel.thibault@ens-lyon.org>:> > Mmm, please try to cast the result of PFN_PHYS into (u_long), as the > format is %lx, not suitable for uint64_t returned by PFN_PHYS. > > Samuel >Hmm... it works. I never paid attention to type casting, because I supposed it worked fine. But I have a bigger concern, that strange PF. Anyway, that''s what crashes the kernel. I do have a "workaround". I can modify the second argument of /* init_page_allocator() */, which indicates max_pfn for the allocator. I hardcode max_pfn, and it''s through. /* periodic_thread */ starts and I get output from serial port. I am not satisfied with that workaround. Maybe I have to start from /* start_xen */ so that I can have an overview of how xen rolls. Thanks for your advice. LIU Wei _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel