Hi, Isaku I'm sorry for lately reply.
>On Wed, Jun 06, 2007 at 04:31:16PM +0900, Akio Takebe wrote: > >> >domain_page_flush_and_put() isn't aware of NULL-owner pages, I'll fix it. >> >However more issues seem to be there. > >I sent out the patch which fixes p2m exposure issues. >But I don't think that the patch doesn't resolve your issues. >At least it only conceals issues. It's worse than panic. > Yes, as you said, when I retried with your patch, dom0 panic is not occurred. I attach the xm dmesg log. (it use the attached patch) >> >> The result of booting domU is below. > >There seems to be several issues. Hmmmm... >What domains correspond to 32896 and 61177984? >I guesss > _domain=61177984 => dom0 > _domain=32896 => newly created domain. >Is those correct? Yes, you're right. >foreign domain page mapping doesn't seem to work correctly. >domain builder seems to map a page which belongs to newly created domain. >If so, it shouldn't be that old_mfn->count_info=0, >old_mfn->u.inuse._domain=0. >Can you confirm the following? > > - Does dom0 issue this hypercall? (i.e. what's currnet domain?) > Yes. This issue seems to be happend at the following hypercalls. xen_ia64_dom_fw_setup: xen_ia64_dom_fw_map (hypercall page=0x0) xen_ia64_dom_fw_setup: xen_ia64_dom_fw_map (fw table=0x2000) xen_ia64_dom_fw_setup: xen_ia64_dom_fw_map (acpi table=0x1000) When I add more debug messages, I get the following message. I specified 512MB of domU memory, so page of gmfn=0x7ffd is start_info page. And page of mfn_or_gmfn =0x0 is fw pages. (XEN) __dom0vp_add_physmap:d 0xf000000007bf0080 domid 0 gpfn 0x1024d6f mfn_or_gmfn 0x1659 flags 0x0 domid 1 (XEN) __dom0vp_add_physmap:d 0xf000000007bf0080 domid 0 gpfn 0x1026800 mfn_or_gmfn 0x7ffc flags 0x0 domid 1 (XEN) __dom0vp_add_physmap:d 0xf000000007bf0080 domid 0 gpfn 0x1026800 mfn_or_gmfn 0x7ffd flags 0x0 domid 1 (XEN) __dom0vp_add_physmap:d 0xf000000007bf0080 domid 0 gpfn 0x1026800 mfn_or_gmfn 0x0 flags 0x0 domid 1 (XEN) __dom0vp_add_physmap:d 0xf000000007bf0080 domid 0 gpfn 0x1026c00 mfn_or_gmfn 0x0 flags 0x0 domid 1 (XEN) __dom0vp_add_physmap:d 0xf000000007bf0080 domid 0 gpfn 0x1027000 mfn_or_gmfn 0x0 flags 0x0 domid 1 (XEN) mfn=0x000000000102003d, old_mfn=0x0000000001020001 (XEN) assign_domain_page_replace: old_mfn->count_info=1155 (XEN) assign_domain_page_replace: mfn->count_info=4 (XEN) assign_domain_page_replace: (domain_id of old_mfn)=32760 (XEN) assign_domain_page_replace: (domain_id of mfn)=1 (XEN) (XEN) Call Trace: (XEN) [<f0000000040ab630>] show_stack+0x80/0xa0 (XEN) sp=f000000007bcfc10 bsp=f000000007bc9350 (XEN) [<f00000000406fab0>] assign_domain_page_replace+0x2d0/0x3d0 (XEN) sp=f000000007bcfde0 bsp=f000000007bc92f8 (XEN) [<f000000004070e80>] __dom0vp_add_physmap+0x370/0x660 (XEN) sp=f000000007bcfde0 bsp=f000000007bc9298 (XEN) [<f0000000040524e0>] do_dom0vp_op+0x1e0/0x4d0 (XEN) sp=f000000007bcfdf0 bsp=f000000007bc9258 (XEN) [<f000000004002e30>] fast_hypercall+0x170/0x340 (XEN) sp=f000000007bcfe00 bsp=f000000007bc9258 > - If so, what's pseudo physical address of dom0? > I guess it is in p2m table table area. Is this correct? > You can find the area by cat /proc/iomem | grep 'Xen p2m table' > or finding dom0 kernel boot message like the following > > > Xen p2m: to [0x0000000300000000, 0x0000000303ffc000) (65536 KBytes) > >If the above guess is correct, then destroying domain shouldn't cause panic. >Can you check mfn which causes panic? > No, the address is not in p2m table. hex(0x1027000 << 14)==> '0x409c000000' # cat /proc/iomem |grep Xen 4094000000-4097ffffff : Xen p2m table Best Regards, Akio Takebe
serial.log
Description: Binary data
patch
Description: Binary data
_______________________________________________ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
