From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Jan Beulich" Subject: Re: long latency of domain shutdown Date: Wed, 14 May 2008 16:54:03 +0100 Message-ID: <482B273B.76E4.0078.0@novell.com> References: <4815FBB8.76E4.0078.0@novell.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Return-path: In-Reply-To: Content-Disposition: inline List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Keir Fraser Cc: xen-devel@lists.xensource.com List-Id: xen-devel@lists.xenproject.org >>> Keir Fraser 28.04.08 16:42 >>> >On 28/4/08 15:30, "Jan Beulich" wrote: > >> Okay, thanks - so I indeed missed the call to hypercall_preempt_check() >> in relinquish_memory(), which is the key indicator here. >>=20 >> However, that change deals exclusively with domain shutdown, but not >> with the more general page table pinning/unpinning operations, which I >> believe are (as described) vulnerable to mis-use by a malicious guest = (I >> realize that well behaved guests would not normally present a heavily >> populated address space here, but it also cannot be entirely excluded) >> - the upper bound to the number of operations on x86-64 is 512**4 >> or 2**36 l1 table entries (ignoring the hypervisor hole which doesn't >> need processing). > >True. It turns out to be good enough in practice though. I'm afraid that's not the case - after they are now using the domain shutdown fix successfully, they upgraded the machine to 64G and the system fails to boot. Sounds exactly like other reports we had on the list regarding boot failures with lots of memory that can be avoided using dom0_mem=3D. As I understand it, this is due to the way the kernel creates its 1:1 mapping - the hypervisor has to validate the whole tree from each L4 entry being installed in a single step - for a 4G machine I measured half a second for this operation, so obviously anything beyond 32G is open for problems when the PM timer is in use. Unless you tell me that this is on your very short term agenda to work on, I'll make an attempt at finding a reasonable solution starting tomorrow. Jan