Collegues say that x86 does not have this problem, however on PowerPC if you: 1) start a domain 2) attach console 3) destroy the domain The xenconsole client stays connected because xenconsoled does not close the PTY. A character on the client will kick the close and all is well. Xenconsoled _does_ get the watch event, but the domain is completely destroyed and xc_domain_getinfo does not find it to eventually close() the PTY It is possible that PowerPC is missing a get_domain(), perhpas by a resource held by xenconsoled? Any thoughts? -JX _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Xenconsoled''s mapping of the console page should keep the domain alive. -- Keir On 12/9/06 2:22 am, "Jimi Xenidis" <jimix@watson.ibm.com> wrote:> > Collegues say that x86 does not have this problem, however on PowerPC if you: > 1) start a domain > 2) attach console > 3) destroy the domain > > The xenconsole client stays connected because xenconsoled does not close > the PTY. A character on the client will kick the close and all is > well. Xenconsoled _does_ get the watch event, but the domain is > completely destroyed and xc_domain_getinfo does not find it to > eventually close() the PTY > > It is possible that PowerPC is missing a get_domain(), perhpas by a > resource held by xenconsoled? > Any thoughts? > -JX > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xensource.com > http://lists.xensource.com/xen-devel_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On Sep 12, 2006, at 3:38 AM, Keir Fraser wrote:> > Xenconsoled''s mapping of the console page should keep the domain > alive. >hmm, I''m having trouble associating the "mapping" and a refcount of some sort somewhere, any pointers? -JX _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On Sep 12, 2006, at 9:05 AM, Jimi Xenidis wrote:> > On Sep 12, 2006, at 3:38 AM, Keir Fraser wrote: > >> >> Xenconsoled''s mapping of the console page should keep the domain >> alive. >> > hmm, I''m having trouble associating the "mapping" and a refcount of > some sort somewhere, any pointers?I see it now, its in the "foreign domain" logic. I thought it would be a page count not a dom count. -JX _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On Tue, 2006-09-12 at 11:16 -0400, Jimi Xenidis wrote:> On Sep 12, 2006, at 9:05 AM, Jimi Xenidis wrote: > > > > > On Sep 12, 2006, at 3:38 AM, Keir Fraser wrote: > > > >> > >> Xenconsoled''s mapping of the console page should keep the domain > >> alive. > >> > > hmm, I''m having trouble associating the "mapping" and a refcount of > > some sort somewhere, any pointers? > > I see it now, its in the "foreign domain" logic. I thought it would > be a page count not a dom count.Actually, why *isn''t* it increasing the page reference count? That would keep the page attached to the domain, which would mean d->tot_pages would stay non-zero, so that would indicate that the domain isn''t ready to be killed yet... -- Hollis Blanchard IBM Linux Technology Center _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On 12/9/06 14:05, "Jimi Xenidis" <jimix@watson.ibm.com> wrote:>> >> Xenconsoled''s mapping of the console page should keep the domain >> alive. >> > hmm, I''m having trouble associating the "mapping" and a refcount of > some sort somewhere, any pointers?See share_xen_page_with_guest() in arch/x86/mm.c. The refcnt is dropped when xenheap_pages field reduces to zero in common/page_alloc.c:free_domheap_pages(). -- Keir _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On 13/9/06 10:23, "Keir Fraser" <Keir.Fraser@cl.cam.ac.uk> wrote:>>> >>> Xenconsoled''s mapping of the console page should keep the domain >>> alive. >>> >> hmm, I''m having trouble associating the "mapping" and a refcount of >> some sort somewhere, any pointers? > > See share_xen_page_with_guest() in arch/x86/mm.c. The refcnt is dropped when > xenheap_pages field reduces to zero in > common/page_alloc.c:free_domheap_pages().Sorry, I''m talking rubbish here. As you say, the relevant code is actually in the foreign mapping paths (e.g., in arch/x86/mm.c). Those paths do a get_page() on the foreign page. This stops it being removed from the domU page list. A non-empty page list holds a reference on the domU. So the domU will not die until that foreign mapping is destroyed. -- Keir _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On Sep 13, 2006, at 5:23 AM, Keir Fraser wrote:> > > > On 12/9/06 14:05, "Jimi Xenidis" <jimix@watson.ibm.com> wrote: > >>> >>> Xenconsoled''s mapping of the console page should keep the domain >>> alive. >>> >> hmm, I''m having trouble associating the "mapping" and a refcount of >> some sort somewhere, any pointers? > > See share_xen_page_with_guest() in arch/x86/mm.c. The refcnt is > dropped when > xenheap_pages field reduces to zero in > common/page_alloc.c:free_domheap_pages().Hmm.. but the console page is a "domain page", no? After looking at more code I convinced myself that a page not owned by the domain but owned by another is "foreign". -JX _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On Sep 13, 2006, at 8:15 AM, Keir Fraser wrote:> > > > On 13/9/06 10:23, "Keir Fraser" <Keir.Fraser@cl.cam.ac.uk> wrote: > >>>> >>>> Xenconsoled''s mapping of the console page should keep the domain >>>> alive. >>>> >>> hmm, I''m having trouble associating the "mapping" and a refcount of >>> some sort somewhere, any pointers? >> >> See share_xen_page_with_guest() in arch/x86/mm.c. The refcnt is >> dropped when >> xenheap_pages field reduces to zero in >> common/page_alloc.c:free_domheap_pages(). > > Sorry, I''m talking rubbish here. As you say, the relevant code is > actually > in the foreign mapping paths (e.g., in arch/x86/mm.c). Those paths > do a > get_page() on the foreign page. This stops it being removed from > the domU > page list. A non-empty page list holds a reference on the domU. So > the domU > will not die until that foreign mapping is destroyed.Whew! -JX _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel