From mboxrd@z Thu Jan 1 00:00:00 1970 From: Olaf Hering Subject: Re: [PATCH] tools: fix build after recent xenpaging changes Date: Fri, 24 Jun 2011 15:32:02 +0200 Message-ID: <20110624133201.GB27793@aepfle.de> References: <20110624121613.GA17634@whitby.uk.xensource.com> <1308918826.32717.85.camel@zakaz.uk.xensource.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Return-path: Content-Disposition: inline In-Reply-To: <1308918826.32717.85.camel@zakaz.uk.xensource.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Ian Campbell Cc: "xen-devel@lists.xensource.com" , Tim Deegan List-Id: xen-devel@lists.xenproject.org On Fri, Jun 24, Ian Campbell wrote: > On Fri, 2011-06-24 at 13:16 +0100, Tim Deegan wrote: > > tools: fix build after recent xenpaging changes > > xenpaging now uses pthreads, so must link appropriately. > > Why does 23625:c49e22648d0e need a new thread to do the page in on exit? > Can't it just signal the main loop to do it? If the page is mappend and the gfn is not there, the attempt to map it may block. I havent tried it, and I think the current code will not block (linux_privcmd_map_foreign_bulk will just loop). If it does block, the mainloop can not proceed and process the page-in request. > Also page_in_trigger doesn't seem safe to me: > +void page_in_trigger(unsigned long gfn) > +{ > + if (!page_in_possible) > + return; > + > + pthread_mutex_lock(&page_in_mutex); > + page_in_gfn = gfn; > + pthread_mutex_unlock(&page_in_mutex); > + pthread_cond_signal(&page_in_cond); > +} > > Two back to back calls to this function (which is what the caller will > do) will both update page_in_gfn without the page in thread necessarily > running in the interim. i.e. the first gfn may be missed. I don't think > pthread_cond_signal makes any guarantees about whether this thread or > the signalled thread will run afterwards. For this approach to woek > page_in_gfn really needs to remain locked until the page in thread has > finished with that particular entry, or you need s return signal, or a > queue, or whatever. Its coded after an example in the APUE book. The page-in thread grabs a copy of page_in_gfn. Are you saying page_in_trigger() can be called more than once while xc_map_foreign_pages()/munmap() is being called? If the caller of page_in_trigger will find the gfn is still in paging state, it will just try again. Olaf