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