[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 10:35:46 +0100
  • Cc: xen devel <xen-devel@xxxxxxxxxxxxxxxxxxx>
  • Delivery-date: Mon, 20 Sep 2010 02:36:30 -0700
  • List-id: Xen developer discussion <xen-devel.lists.xensource.com>
  • Thread-index: ActYpGE8J0BOQKScRY+Ci+ESwGQAkgAAtJzg
  • Thread-topic: VM hung after running sometime

On 20/09/2010 10:15, "MaoXiaoyun" <tinnycloud@xxxxxxxxxxx> wrote:

> Thanks Keir.
>  
> You're right, after I deeply looked into the wait_on_xen_event_channel, it is
> smart enough
> to avoid the race I assumed.
>  
> How about prepare_wait_on_xen_event_channel ?
> Currently Istill don't know when it will be invoked.
> Could enlighten me?

As you can see it is called from hvm_send_assist_req(), hence it is called
whenever an ioreq is sent to qemu-dm. Note that it is called *before*
qemu-dm is notified -- hence it cannot race the wakeup from qemu, as we will
not get woken until qemu-dm has done the work, and it cannot start the work
until it is notified, and it is not notified until after
prepare_wait_on_xen_event_channel has been executed.

 -- Keir

>  
>> Date: Mon, 20 Sep 2010 08:45:21 +0100
>> Subject: Re: VM hung after running sometime
>> From: keir.fraser@xxxxxxxxxxxxx
>> To: tinnycloud@xxxxxxxxxxx
>> CC: xen-devel@xxxxxxxxxxxxxxxxxxx; jbeulich@xxxxxxxxxx
>> 
>> 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®.