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

[MaoXiaoyun <tinnycloud@xxxxxxxxxxx>]

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?

 
> 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 be fore 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