[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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.