Re: Sched_op hypercall small questions

[Jeremy Fitzhardinge <jeremy@goop.org>]

On 09/19/2011 11:17 PM, Daniel Castro wrote:
> On Tue, Sep 20, 2011 at 2:41 PM, Keir Fraser <keir.xen@gmail.com> wrote:
>> On 19/09/2011 22:21, "Daniel Castro" <evil.dani@gmail.com> 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?

You specify the timeout in the the form "wake up by time t".  If t is in
the past, it times out immediately.

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

If you have events unmasked and you get an unmasked event, then it will
go into the event handler.

>>> 3. If I issue the hypercall and the event never comes is it possible
>>> to to yield the CPU for ever?
>> Yes, if you do not specify a timeout.
> Keir thanks for the answer.
>
> 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
> 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.

It generally only makes sense to poll on masked events.

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

What environment is this in?

    J