From mboxrd@z Thu Jan 1 00:00:00 1970 From: Anthony Liguori Subject: Re: yanked share, round 2 Date: Fri, 13 Jan 2006 13:23:18 -0600 Message-ID: <43C7FE26.4010501@us.ibm.com> References: <44BDAFB888F59F408FAE3CC35AB4704102C2667C@orsmsx409> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <44BDAFB888F59F408FAE3CC35AB4704102C2667C@orsmsx409> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: "King, Steven R" Cc: xen-devel@lists.xensource.com List-Id: xen-devel@lists.xenproject.org An ideal solution to this problem would be to keep a separate pool of shared memory that neither domain owned. That removes any concerns about ownership. Regards, Anthony Liguori King, Steven R wrote: > Hi folks, > A previous thread discussed complications around DomU's sharing memory > pages with each other: > http://lists.xensource.com/archives/html/xen-devel/2005-12/msg00499.html > > To summarize, DomU's get into trouble, e.g. unable to shutdown, > unless the remote DomU's play nice. Since DomU's do not trust each > other, that is problematic. I'd like to discuss how to clean away > this dependency. > > Here's one idea. The goal is to robustly decouple the sharing and > remote domains. > > Grant tables add a new GTF_safe flag, settable by the sharing DomU. > In order to map a GTF_safe page, a remote domain must provide a page > of its own, which I'll call an "under page". > Xen holds the under-page on behalf of the remote DomU and maps > the shared page into the remote DomU's machine. > At any time, the sharing DomU can unshare the page, crash, etc, > which ends ALL foreign access to that page, not just new mappings. > For each remote domain that still maps the unshared page, Xen maps the > remote's under-page in place of the unshared page. > The remote domain can unmap at any time and recover its under-page. > > The purpose of the under-page is to plug the memory hole in the remote > DomU created by a surprise unsharing. A nervous remote DomU could > check that a share is GTF_safe before proceeding to map the page. > > Good, bad or ugly? > -steve > > > > >------------------------------------------------------------------------ > >_______________________________________________ >Xen-devel mailing list >Xen-devel@lists.xensource.com >http://lists.xensource.com/xen-devel > >