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

[Xen-devel] Sched_op hypercall small questions

To: xen-devel@xxxxxxxxxxxxxxxxxxx
Subject: [Xen-devel] Sched_op hypercall small questions
From: Daniel Castro <evil.dani@xxxxxxxxx>
Date: Thu, 22 Sep 2011 14:41:20 +0900
Delivery-date: Wed, 21 Sep 2011 22:42:30 -0700
Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; bh=/Epz7DNKRXt+TfB9qWNhubN9oyStdeudn3WrQXr4AKc=; b=Wcl4UR85+sLUNTWHc0luV0gBMZHJRAf1Jn1rEPw8Qg84JPvlJt4t7kz+yF7uKVIFQX 61rv3oFQhlNJJHhN2cKwl+fDGrNZ+oaOHb7zLMX0MWt9PgXg4fBAndpBX2ONDszort4U dLLnd6noVvnoY5ekjYEZJhVVaUKnm8yKB9txc=
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <CAP2B859vtSK_tC0J6HWB_m6hjHKM18vZ7Qh6ABFejCiEfxs+6g@xxxxxxxxxxxxxx>
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>
References: <CAP2B85_rPbB=hZpKJYSPgC59jU=YG6deD4ZkWMmXwtMV4un1mg@xxxxxxxxxxxxxx> <CA9D757C.2119E%keir.xen@xxxxxxxxx> <CAP2B85-e64NKts_iC21Bh0OL3X3nUh4jLriYfE2+stHkPfMFWg@xxxxxxxxxxxxxx> <4E793DC4.7080808@xxxxxxxx> <CAP2B859vtSK_tC0J6HWB_m6hjHKM18vZ7Qh6ABFejCiEfxs+6g@xxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
On Wed, Sep 21, 2011 at 10:28 AM, Jeremy Fitzhardinge <jeremy@xxxxxxxx> wrote:
> On 09/19/2011 11:17 PM, Daniel Castro wrote:
>> On Tue, Sep 20, 2011 at 2:41 PM, Keir Fraser <keir.xen@xxxxxxxxx> wrote:
>>> On 19/09/2011 22:21, "Daniel Castro" <evil.dani@xxxxxxxxx> 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.

My vcpu[0].evntchn_upcall_mask is 0, does this prevents the guest from
receiving events? would that also explain why poll hypercall returns
immediately? According to Xen's Definitive Guide evntchn_upcall_mask
is unset at boot (my case exactly) so if it is 0 from the start and
the guest (me) has to change it to 1 in order to receive events. How
can I change the flag, I tried changing the value but it does not work
like that apparently.

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



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



-- 
+-=====---------------------------+
| +---------------------------------+ | 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