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] yanked share, round 2

To: xen-devel@xxxxxxxxxxxxxxxxxxx
Subject: Re: [Xen-devel] yanked share, round 2
From: Mark Williamson <mark.williamson@xxxxxxxxxxxx>
Date: Sat, 14 Jan 2006 16:21:07 +0000
Cc: "King, Steven R" <steven.r.king@xxxxxxxxx>
Delivery-date: Sat, 14 Jan 2006 16:28:19 +0000
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <44BDAFB888F59F408FAE3CC35AB4704102C26721@orsmsx409>
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/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <44BDAFB888F59F408FAE3CC35AB4704102C26721@orsmsx409>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: KMail/1.9.1
> Hi Keir, I'm not familiar enough with zombie anatomy to help there, so let
> me try this reasoning: today's Xen architecture cannot promise that a
> shared page can ever be returned to normal, non-shared service.  Thus, any
> DomU that routinely creates shared pages *must* eventually run out of
> memory.

Eveni if it could reboot, causing the control tools to allocate it new 
memory... the more worrying problem is that a domain that does *not* return 
shared pages could eventually end up holding all the memory in the machine, 
with it all being credited to other (zombie) domains.

> Of course if all DomU's try to play nice, it would take a long 
> while.  We still face a snag in which Xen allows DomU bugs, DomU crashes
> and DomU evil to accumulate over time.  By analogy to the hardware world, a
> PCI device that could not promise to let go of pages would be unacceptable.

A centralised store (managed by a trusted entity) would be rather good for 
domUs that really don't trust each other.  It'd be worth having a driver that 
could set these up - presumably with shares advertised using XenStore.


> -steve
> -----Original Message-----
> From: Keir Fraser [mailto:Keir.Fraser@xxxxxxxxxxxx]
> Sent: Friday, January 13, 2006 11:21 AM
> To: King, Steven R
> Cc: xen-devel@xxxxxxxxxxxxxxxxxxx
> Subject: Re: [Xen-devel] yanked share, round 2
> On 13 Jan 2006, at 19:07, King, Steven R wrote:
> > 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?
> What's wrong with the current scheme (sharing domU sticks around as a
> zombie until foreign mappings disappear)? This needn't stop control tools
> from restarting the domain (they can see that it has shut down, for
> example, and is simply awaiting reaping when its refcnt falls to zero).
> It's arguable the zombies needn't even be kept on the domain list, so they
> become invisible to the control tools (since they're really just a resource
> container for foreign page mappings). OTOH hiding things from control tools
> is probably a bad idea. :-)
>   -- Keir
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@xxxxxxxxxxxxxxxxxxx
> http://lists.xensource.com/xen-devel

Dave: Just a question. What use is a unicyle with no seat?  And no pedals!
Mark: To answer a question with a question: What use is a skateboard?
Dave: Skateboards have wheels.
Mark: My wheel has a wheel!

Xen-devel mailing list