From mboxrd@z Thu Jan 1 00:00:00 1970 From: Keir Fraser Subject: Re: long latency of domain shutdown Date: Thu, 08 May 2008 15:38:14 +0100 Message-ID: References: <48232A53.76E4.0078.0@novell.com> Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <48232A53.76E4.0078.0@novell.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Jan Beulich Cc: xen-devel@lists.xensource.com List-Id: xen-devel@lists.xenproject.org On 8/5/08 15:29, "Jan Beulich" wrote: > Hmm, storing this in page_info seems questionable to me. It'd be at > least 18 bits (on x86-64) that we'd need. I think this rather has to go > into struct vcpu. We can, for example, reuse tlbflush_timestamp for this purpose. Stick it in the vcpu structure and I think we make life hard for ourselves. What if the guest does not resume the hypercall, for example? What if the guest goes and tries to execute a different hypercall instead? > But what worries me more is that (obviously) any affected page will > have to have its PGT_validated bit kept clear, which could lead to > undesirable latencies in spin loops on other vcpus waiting for it to > become set. In the worst case this could lead to deadlocks (at least > in the UP case or when multiple vCPU-s of one guest are pinned to > the same physical CPU) afaics. Perhaps this part could indeed be > addressed with a new PGT_* bit, upon which waiters could exit > their spin loops and consider themselves preempted. Yes, the page state machine does need some more careful thought. I'm pretty sure we have enough page state bits though. -- Keir