[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] RE: [Xen-devel] yanked share, round 2
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
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |