The file you're looking for re getting an event channel is
xen/common/schedule.c, the common scheduling code.
In schedule.c, vcpu_wake() will always call the scheduler wake()
function; However, event channels and other "you have an event"
functions call call vcpu_unblock() instead, which will check the
vcpu's VPF_blocked flag and only call vcpu_wake if it was set.
You could try changing vcpu_unblock() to always call vcpu_wake() for
your experimental development; I'm not sure what side-effects this
Regarding tracing IO_READs: The code that did IO was refactored some
time back; I remember trying to figure out how to cleanly do the
tracing, but finding it difficult. I can't remember now, though, what
the issue was. Let me take a look again.
On Fri, Oct 8, 2010 at 1:25 AM, Yuehai Xu <yuehaixu@xxxxxxxxx> wrote:
>> I originally considered that when a Dom has an I/O event, its VCPU
>> would be waken up, in another word, csched_vcpu_wake(struct vcpu *vc)
>> should be invoked. However, I find I am definitely wrong. As long as
>> there is a CPU intensive program running in a Dom, this Dom should
>> never be in a state of "sleep"? In another word, it should never be
>> waken up?
> The trace result from xenalyze confirms that when a VM has a running
> CPU intensive program, it never needs to be waken up. So, my question
> is, how can I schedule a VM that has I/O event immediately even this
> VM is CPU intensive? I think it is impossible to implement it in the
> function csched_vcpu_wake.
> Also, is it possible to trace the I/O procedure by xenalyze? I notice
> even the macro TRC_HVM_IO_READ is defined, I don't find it is used in
> Xen-devel mailing list
Xen-devel mailing list