From mboxrd@z Thu Jan 1 00:00:00 1970 From: Keir Fraser Subject: Re: VM hung after running sometime Date: Mon, 20 Sep 2010 08:45:21 +0100 Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: MaoXiaoyun Cc: xen devel List-Id: xen-devel@lists.xenproject.org On 20/09/2010 07:00, "MaoXiaoyun" wrote: > When IO is not ready, domain U in VMEXIT->hvm_do_resume might invoke > wait_on_xen_event_channel > (where it is blocked in _VPF_blocked_in_xen). > > Here is my assumption of event missed. > > step 1: hvm_do_resume execute 260, and suppose p->state is STATE_IOREQ_READY > or STATE_IOREQ_INPROCESS > step 2: then in cpu_handle_ioreq is in line 547, it execute line 548 so > quickly before hvm_do_resume execute line 270. > Well, the event is missed. > In other words, the _VPF_blocked_in_xen is cleared before it is actually > setted, and Domian U who is blocked > might never get unblocked, it this possible? Firstly, that code is very paranoid and it should never actually be the case that we see STATE_IOREQ_READY or STATE_IOREQ_INPROCESS in hvm_do_resume(). Secondly, even if you do, take a look at the implementation of wait_on_xen_event_channel() -- it is smart enough to avoid the race you mention. -- Keir