Re: [Xen-devel] Sched_op hypercall small questions

[Daniel Castro <evil.dani@xxxxxxxxx>]

On Tue, Sep 20, 2011 at 4:33 PM, Jan Beulich <jbeulich@xxxxxxxx> wrote:
>>>> 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".

My Guest VM would get stuck on the hypercall call, like if it was an
infinite loop?
And once the timeout occurs or the event get delivered, then the
hypercall would return, right?

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



-- 
+-=====---------------------------+
| +---------------------------------+ | This space intentionally blank
for notetaking.
| |   | Daniel Castro,                |
| |   | Consultant/Programmer.|
| |   | U Andes                         |
+-------------------------------------+

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel