[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Xen-devel] Re: VM hung after running sometime


  • To: MaoXiaoyun <tinnycloud@xxxxxxxxxxx>
  • From: Keir Fraser <keir.fraser@xxxxxxxxxxxxx>
  • Date: Mon, 20 Sep 2010 08:45:21 +0100
  • Cc: xen devel <xen-devel@xxxxxxxxxxxxxxxxxxx>
  • Delivery-date: Mon, 20 Sep 2010 00:46:32 -0700
  • List-id: Xen developer discussion <xen-devel.lists.xensource.com>
  • Thread-index: ActYiSXFV0XjJxfYQcGaIcmGEaHK1gADqEYN
  • Thread-topic: VM hung after running sometime

On 20/09/2010 07:00, "MaoXiaoyun" <tinnycloud@xxxxxxxxxxx> 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



_______________________________________________
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®.