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: "michele.paolino" <michele.paolino@xxxxxxxxxxxxxxx>
Subject: Re: [Xen-devel] generate random numbers
From: George Dunlap <george.dunlap@xxxxxxxxxxxxx>
Date: Mon, 1 Mar 2010 11:41:23 +0000
Cc: "Xen-devel@xxxxxxxxxxxxxxxxxxx" <Xen-devel@xxxxxxxxxxxxxxxxxxx>
Delivery-date: Mon, 01 Mar 2010 03:43:49 -0800
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <14f366f91002261054r593aa3d1wc3de3fa7fbc1257d@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: <14f366f91002111231reae2e41vc8f823b38e16a76b@xxxxxxxxxxxxxx> <AEC6C66638C05B468B556EA548C1A77D01899202@trantor> <14f366f91002120032uc08b7d6sb2283e10c9444bbf@xxxxxxxxxxxxxx> <de76405a1002120415l717292e6g484a342337ac414b@xxxxxxxxxxxxxx> <14f366f91002121442h536a2d03if7d9bdee416a4a23@xxxxxxxxxxxxxx> <1266016370.15135.2942.camel@xxxxxxxxxxxxxxxxxxxxxxx> <14f366f91002251031g538dcffan9fe5208b5d981444@xxxxxxxxxxxxxx> <4B86EADC.70301@xxxxxxxxxxxxx> <14f366f91002260943n203faba8r79b3c0d4d5d7622d@xxxxxxxxxxxxxx> <4B880897.6080205@xxxxxxxxxxxxx> <14f366f91002261054r593aa3d1wc3de3fa7fbc1257d@xxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Thunderbird (X11/20090817)
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>