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] 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 2.0.0.23 (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."

-George

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

Michele


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?
    -George

    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?

        Michele

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

           The problem is that you're choosing a random vcpu to run,
        without
           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
        yet).

           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
        schedule().

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

           -George


           michele.paolino wrote:

               Here's my random scheduler. It works until I start a
        virtual
               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
        NOW()
               function.
               I would also Know why at boot time there are two calls at
               vcpu_init function for vcpu with id = 0 ??

               Thanks
               Michele







_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel

<Prev in Thread] Current Thread [Next in Thread>