[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-ia64-devel] [Q] about assign_domain_page_replace
On Tue, Jun 05, 2007 at 08:58:16PM +0900, Akio Takebe wrote: > Is the following patch right? > > diff -r aee991c7723a xen/arch/ia64/xen/mm.c > --- a/xen/arch/ia64/xen/mm.c Wed May 09 16:34:47 2007 +0100 > +++ b/xen/arch/ia64/xen/mm.c Wed Jun 06 05:41:15 2007 +0900 > @@ -1121,7 +1121,7 @@ assign_domain_page_replace(struct domain > if (pte_mem(old_pte)) { > unsigned long old_mfn = pte_pfn(old_pte); > > - // mfn = old_mfn case can happen when domain maps a granted page > + // mfn != old_mfn case can happen when domain maps a granted page > // twice with the same pseudo physial address. > // It's non sense, but allowed. > // __gnttab_map_grant_ref() > No. It describes that "mfn == old_mfn" case can happen in theory. In that case, domain_put_page() shouldn't called. Probably my english is broken so that english refinement is necessary. > If so, I have one more question. > When assign_domain_page_replace() is called from __dom0vp_add_physmap(), > there are a case of mfn != old_mfn. > Is that correct case or a bug? > At that time, old_mfn->count_info=0. "mfn != old_mfn" itself isn't a bug of Xen VMM. It should be okay from the hypervisor point of view. In both case (== and !=), Xen VMM should continue to work finely. domain_put_page() makes mfn_to_page(old_mfn)->count_info = 0 and frees the page. On the other hand, "pte_mem(old_pte) == true" is a bad sign from the dom0 point of view. (the current domain is dom0, right?) domain shouldn't assign new page to pseudo physicall address which page is already assigned to. I.e. usually pte_mem(old_pte) is false. Dom0 seems to work badly. > So if I destroy the domain, hypervisor panic like the below. > > (XEN) Xen BUG at mm.c:233 > (XEN) FIXME: implement ia64 dump_execution_state() > (XEN) **************************************** > (XEN) Panic on CPU 1: > (XEN) Xen BUG at mm.c:233 > (XEN) **************************************** > (XEN) > (XEN) Reboot in five seconds... mm.c:233 isn't BUG_ON() in my tree. Does it correspond to mm.c:232 in xen-ia64-unstable.hg of c/s 15162:0cf6b75423e9? If so, the pte entry is already updated to point to mfn so that old_mfn shouldn't be involved. Could you elaborate on details? - paravirtualized domain or domVTi? - What is the activity to trigger assign_domain_page_replace() with pte_mem(old_pte) true? thanks, -- yamahata _______________________________________________ Xen-ia64-devel mailing list Xen-ia64-devel@xxxxxxxxxxxxxxxxxxx http://lists.xensource.com/xen-ia64-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |