[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: [Xen-devel] yanked share, round 2


  • To: "Anthony Liguori" <aliguori@xxxxxxxxxx>
  • From: "King, Steven R" <steven.r.king@xxxxxxxxx>
  • Date: Fri, 13 Jan 2006 11:31:22 -0800
  • Cc: xen-devel@xxxxxxxxxxxxxxxxxxx
  • Delivery-date: Fri, 13 Jan 2006 19:38:11 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xensource.com>
  • Thread-index: AcYYdvFcnjYUU4gjS1SbIkp3bF/p4QAABssQ
  • Thread-topic: [Xen-devel] yanked share, round 2

Hi Anthony -- Can you explain why this is ideal?  I prefer that sharers
and mappers have their own skin the game--that way, Xen doesn't have to
manage a pool and nobody has to worry about the pool being depleted.

-----Original Message-----
From: Anthony Liguori [mailto:aliguori@xxxxxxxxxx] 
Sent: Friday, January 13, 2006 11:23 AM
To: King, Steven R
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx
Subject: Re: [Xen-devel] yanked share, round 2

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.ht
> ml
>  
> 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@xxxxxxxxxxxxxxxxxxx
>http://lists.xensource.com/xen-devel
>  
>

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.