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: Jan Beulich <jbeulich@xxxxxxxx>
Subject: Re: [Xen-devel] Sched_op hypercall small questions
From: Daniel Castro <evil.dani@xxxxxxxxx>
Date: Tue, 20 Sep 2011 17:31:36 +0900
Cc: keir.xen@xxxxxxxxx, xen-devel@xxxxxxxxxxxxxxxxxxx
Delivery-date: Tue, 20 Sep 2011 01:32:32 -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 :cc:content-type:content-transfer-encoding; bh=3f8T1BQX8s3jPWLay9aSO0IZMYRwFmkB9U4NpLrdQQA=; b=uCF0GgmYVmRSwTRzUoTfVpk5ZXJvNfrI+leT8WHkzfkYpIcVmNBTik+yGJnQIywYm9 R0LoFunJep7O0Fy2dUkVfbXMddeUbwan8YMV/md244spr+r1HRVKDoEf4d5lZ1h1Vf2C Wct+m/gzi+wQ6j+9vzcoe9vyUUuXS3fHDxzU8=
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <4E784FD502000078000769C5@xxxxxxxxxxxxxxxxxxxx>
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: <4E784FD502000078000769C5@xxxxxxxxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
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