>>> Daniel Castro 09/20/11 8:18 AM >>>
>On Tue, Sep 20, 2011 at 2:41 PM, Keir Fraser wrote:
>> On 19/09/2011 22:21, "Daniel Castro" wrote:
>>
>>> Greetings all.
>>>
>>> Some small question regarding schedule poll operation hypercall.
>>>
>>> 1. struct sched_poll poll.timeout is measured in what unit of time?
>>> Secs, ms? ns?
>>
>> It is an absolute system time (rather than a duration), in nanoseconds.
>
>really an absolute system time?
>
>When the timeout is set and the timeout is reached, the system behaves
>like if the event had been received? i.e the bit is changed?
No, the bit would remain unset - the poll times out then, it doesn't
"complete".
>>> 2. After issuing the hypercall_sched_op(SCHEDOP_poll, &poll); if no
>>> timeout is used in poll struct how long will I yield the CPU?
>>
>> Until one of the specified event channel ports is pending.
>If the channel port never changes (the event never arrives) then I
>would yield for ever?
Yes.
>I am trying to read from xenstore, so I have the following:
>I write on my xenstore ring the query I want, then,
>hypercall_event_channel_op(EVTCHNOP_send ...
>If I read the ring inmediatly the answer is not ready so I issue a
That would suggest an ordering problem on either or both sides.
>hypercall_sched_op(SCHEDOP_poll, &poll);
>But while I am entering the yield state the answer comes, so the event
>is never seen because it has already been delivered.
>
>If I use some way to wait (just for very brief instant) after the
>event_channel_op send then, when I check the ring the answer is there;
>And I do not need to yield the CPU.
>
>Should I issue the wait after the send, rather than when I am about to
>read the answer?
When you start the wait really shouldn't matter. But ordering needs
to be in place so that the event only gets signaled when the consuming
side can actually see what the producer put into the shared data
structure. Since the signaling is done through a hypercall, there
shouldn't really be anything the producer needs to do (unless your
shared data is not in memory).
Jan
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home