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 17:05:20 +0100 Message-ID: <482B29E0.76E4.0078.0@novell.com> References: <4815FBB8.76E4.0078.0@novell.com> <482B273B.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: <482B273B.76E4.0078.0@novell.com> 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 , Jan Beulich Cc: xen-devel@lists.xensource.com List-Id: xen-devel@lists.xenproject.org >>> "Jan Beulich" 14.05.08 17:54 >>> >>>> 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 Sorry, I meant to write 1/8th of a second. But that's on a small (and hence memory-wise faster) machine. Didn't measure on my bigger box, yet. >obviously anything beyond 32G is open for problems when the PM timer >is in use. This number wasn't consistent then either - the boundary would rather be around 64G on that system, but obviously lower on others. Jan