This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Home Products Support Community News


Re: [Xen-devel] [PATCH] tools: fix build after recent xenpaging changes

To: Ian Campbell <Ian.Campbell@xxxxxxxxxx>
Subject: Re: [Xen-devel] [PATCH] tools: fix build after recent xenpaging changes
From: Olaf Hering <olaf@xxxxxxxxx>
Date: Fri, 24 Jun 2011 15:32:02 +0200
Cc: "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>, Tim Deegan <Tim.Deegan@xxxxxxxxxx>
Delivery-date: Fri, 24 Jun 2011 06:32:38 -0700
Dkim-signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1308922323; l=1790; s=domk; d=aepfle.de; h=In-Reply-To:Content-Type:MIME-Version:References:Subject:Cc:To:From: Date:X-RZG-CLASS-ID:X-RZG-AUTH; bh=8LzTg+XvhKTYs3hSgqnjBWVD/qI=; b=bd8h6zvdCy+oC1W+spO6y+sJUdj+6mY39dRcL1ZxchDzKmxPOW1mqCPmSCH3w0dZhag RQ3lxs9tDktBmRMeQtRz+b8A++3NzqVrYcnG5tgPpXZjAhb4WbJdzhO0U5s1etcaFmjXu wvbNVpeJsPxpB29MUATBx1M1gTtjulHOnz0=
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <1308918826.32717.85.camel@xxxxxxxxxxxxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <20110624121613.GA17634@xxxxxxxxxxxxxxxxxxxxxxx> <1308918826.32717.85.camel@xxxxxxxxxxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Mutt/1.5.21 (2010-12-30)
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

> 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.


Xen-devel mailing list