Re: long latency of domain shutdown

["Jan Beulich" <jbeulich@novell.com>]

>>> "Jan Beulich" <jbeulich@novell.com> 14.05.08 17:54 >>>
>>>> Keir Fraser <keir.fraser@eu.citrix.com> 28.04.08 16:42 >>>
>>On 28/4/08 15:30, "Jan Beulich" <jbeulich@novell.com> 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

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