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

On 13 Jan 2006, at 19:55, King, Steven R wrote:

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.

Just as a PCI device can be reset, we can kill an offensive device driver or other service domain and restart it. I think these problems need addressing in the tools / control plane, not with extra mechanism in Xen. At the end of the day, the memory backing these bogus/buggy mappings has to come from somewhere. Even if you add mechanism such that the mapping domain is made accountable, what should its clients do when it runs out of memory and finally hits the brick wall?

 -- Keir

Xen-devel mailing list