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.
>> 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
>>> (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
>> -- Keir
Xen-devel mailing list