Re: yanked share, round 2

[Anthony Liguori <aliguori@us.ibm.com>]

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