From: "Jan Beulich" <jbeulich@novell.com>
To: Keir Fraser <keir.fraser@eu.citrix.com>
Cc: xen-devel@lists.xensource.com
Subject: Re: long latency of domain shutdown
Date: Wed, 14 May 2008 16:54:03 +0100 [thread overview]
Message-ID: <482B273B.76E4.0078.0@novell.com> (raw)
In-Reply-To: <C43BA0D1.1FFA9%keir.fraser@eu.citrix.com>
>>> 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
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
next prev parent reply other threads:[~2008-05-14 15:54 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-04-28 13:45 long latency of domain shutdown Jan Beulich
2008-04-28 13:59 ` Keir Fraser
2008-04-28 14:30 ` Jan Beulich
2008-04-28 14:42 ` Keir Fraser
2008-05-14 15:54 ` Jan Beulich [this message]
2008-05-14 16:05 ` Jan Beulich
2008-05-14 16:08 ` Keir Fraser
[not found] <48189781.76E4.0078.0@novell.com>
[not found] ` <C43E4040.2022A%keir.fraser@eu.citrix.com>
2008-05-08 9:58 ` Jan Beulich
2008-05-08 10:12 ` Keir Fraser
2008-05-08 10:39 ` Jan Beulich
2008-05-08 10:52 ` Keir Fraser
2008-05-08 11:13 ` Jan Beulich
2008-05-08 12:11 ` Keir Fraser
2008-05-08 12:33 ` Jan Beulich
2008-05-08 12:36 ` Keir Fraser
2008-05-08 14:29 ` Jan Beulich
2008-05-08 14:38 ` Keir Fraser
2008-05-09 10:23 ` Jan Beulich
2008-05-09 10:29 ` Keir Fraser
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=482B273B.76E4.0078.0@novell.com \
--to=jbeulich@novell.com \
--cc=keir.fraser@eu.citrix.com \
--cc=xen-devel@lists.xensource.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.