[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] long latency of domain shutdown
>>> Keir Fraser <keir.fraser@xxxxxxxxxxxxx> 28.04.08 16:42 >>> >On 28/4/08 15:30, "Jan Beulich" <jbeulich@xxxxxxxxxx> wrote: > >> Okay, thanks - so I indeed missed the call to hypercall_preempt_check() >> in relinquish_memory(), which is the key indicator here. >> >> 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=<much smaller value>. 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 _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxx http://lists.xensource.com/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |