WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

Re: [Xen-devel] Sched_op hypercall small questions

To: <evil.dani@xxxxxxxxx>
Subject: Re: [Xen-devel] Sched_op hypercall small questions
From: "Jan Beulich" <jbeulich@xxxxxxxx>
Date: Tue, 20 Sep 2011 08:33:24 +0100
Cc: keir.xen@xxxxxxxxx, xen-devel@xxxxxxxxxxxxxxxxxxx
Delivery-date: Tue, 20 Sep 2011 00:34:30 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
>>> 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