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/
Home Products Support Community News


Re: [Xen-devel] generate random numbers

To: George Dunlap <george.dunlap@xxxxxxxxxxxxx>
Subject: Re: [Xen-devel] generate random numbers
From: "michele.paolino" <michele.paolino@xxxxxxxxxxxxxxx>
Date: Mon, 1 Mar 2010 17:56:46 +0100
Cc: "Xen-devel@xxxxxxxxxxxxxxxxxxx" <Xen-devel@xxxxxxxxxxxxxxxxxxx>
Delivery-date: Mon, 01 Mar 2010 08:58:10 -0800
Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:from:date:x-google-sender-auth:message-id:subject:to:cc :content-type; bh=QUNkQyILj+Y0Sn5hUw+i942P2bWLrPNWmpgyo/M7vwo=; b=A8LCehZd0h4ANs/+B2wB+1oAGjF9ZvjhoyRlOgfG+vzgmTTJ5BSbaWQQV+oKVUQ9iM n5F+rGYxC82rxWQ/3MuK46uXiE0mLeGVxLX7C0IGn8vuPEqXar2SIWNFilnM5XaePzFv 67pvgDM6xn/9OTnt7sqMqeadNkwY8eQNgrCvg=
Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type; b=AiC/hnB8KBjglym+fgUvzqFCu2ETX6jc1mjLrdUWOIjMW5j5HuZZlpV9d1jbd8QgIH X03MIxmpFd+6a1Wjz0e773imtwTChwXWN5NKU7fdSG6PVny2H+yD6Q+KgQ7tA/NOGDMn UNye+cMZYrSiPwD2AtuKur/b6lRb5diGvhvTo=
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <4B8BA7E3.50700@xxxxxxxxxxxxx>
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: <14f366f91002111231reae2e41vc8f823b38e16a76b@xxxxxxxxxxxxxx> <de76405a1002120415l717292e6g484a342337ac414b@xxxxxxxxxxxxxx> <14f366f91002121442h536a2d03if7d9bdee416a4a23@xxxxxxxxxxxxxx> <1266016370.15135.2942.camel@xxxxxxxxxxxxxxxxxxxxxxx> <14f366f91002251031g538dcffan9fe5208b5d981444@xxxxxxxxxxxxxx> <4B86EADC.70301@xxxxxxxxxxxxx> <14f366f91002260943n203faba8r79b3c0d4d5d7622d@xxxxxxxxxxxxxx> <4B880897.6080205@xxxxxxxxxxxxx> <14f366f91002261054r593aa3d1wc3de3fa7fbc1257d@xxxxxxxxxxxxxx> <4B8BA7E3.50700@xxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
I'm really sorry, maybe I misunderstood your mail.  I don't want anyone to work for me.:-)
I looked at the functions listed in Xen call trace...I think my problem is the timer variable called periodic_timer of struct vcpu.
In function remove_entry() there is a switch/case construct that check if vcpu->periodic_timer->status is initialized at TIMER_STATUS_in_heap or TIMER_STATUS_in_list. Which one should I use?
Should Initialize it at one of timer status defined in timer.h file?


On Mon, Mar 1, 2010 at 12:41 PM, George Dunlap <george.dunlap@xxxxxxxxxxxxx> wrote:
If you want us to spend some of our time helping you, you need to demonstrate that you've tried to spend some time helping yourself.  How might rc come to be 0 at that line?  What is remove_entry() doing?  How could this have come about because of something your code did?

An example mail that would get more help would be something like this:

"I've looked at the remove_entry() function, and it seems that the bug can be triggered if the input is {some condition}.  I looked at where remove_entry() is being called, but I can't figure out how it can get that condition because of my code."


michele.paolino wrote:
Line 184 correspond at rc = 0 (an int variable) of remove_entry() function. I don't have modified that file.


On Fri, Feb 26, 2010 at 6:44 PM, George Dunlap <george.dunlap@xxxxxxxxxxxxx <mailto:george.dunlap@xxxxxxxxxxxxx>> wrote:

   Did you look at timer.c, line 184, to find out what the BUG is?

   michele.paolino wrote:

       Following George's advices I have rewrited my scheduler. But
       now serial console's log report me a bug in a function of timer.c

       (XEN) ****************************************
       (XEN) Panic on CPU 0:
       (XEN) Xen BUG at timer.c:184
       (XEN) ****************************************

       This is caused by cpumask_raise_softirq() in my wake()
       function. What can I do?


       On Thu, Feb 25, 2010 at 10:25 PM, George Dunlap
       <mailto:george.dunlap@xxxxxxxxxxxxx>>> wrote:

          The problem is that you're choosing a random vcpu to run,
          considering whether it *wants* to run or not.  In this case,
          you're running a vcpu before it's even been completely set
       up yet
          (write_cr3 is failing because the guest *has* no cr3 ready

          The normal way schedulers deal with this is to keep one list of
          all vcpus (or all domains), and another list with "runnable"
          vcpus.  You can keep track of which vcpus are runnable with the
          vcpu_wake() callback and by using vcpu_runnable() in

          At very least, your loop in schedule should check
          before selecting it.


          michele.paolino wrote:

              Here's my random scheduler. It works until I start a
              machine (error file attached is the serial console's log).
              In xen call trace there isn't any of my functions.
              To generate random numbers I'm using the hash (MD5) of
              I would also Know why at boot time there are two calls at
              vcpu_init function for vcpu with id = 0 ??


Xen-devel mailing list
<Prev in Thread] Current Thread [Next in Thread>