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

["King, Steven R" <steven.r.king@xxxxxxxxx>]

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

-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