* Kernel panic, reboot in 5 seconds
@ 2015-05-14 13:00 Mr Idris
2015-05-18 11:00 ` George Dunlap
0 siblings, 1 reply; 6+ messages in thread
From: Mr Idris @ 2015-05-14 13:00 UTC (permalink / raw)
To: xen-devel
I'm trying to create cpu scheduler on xen 4.4.1 using debian 7 which
inspired by arinc653 scheduler. When i use it, it gives me something
like kernel panic and reboot in 5 secs before go in to the system. I
don't know how to procced to fix the errors, Here is some debug
errors :
(XEN) Debugging connection not set up.
(XEN) ----[ Xen-4.4.1 x86_64 debug=y Not tainted ]----
(XEN) CPU: 0
(XEN) RIP: e008:[<ffff82d080126dbe>] schedule+0x408/0x5df
(XEN) RFLAGS: 0000000000010006 CONTEXT: hypervisor
(XEN) rax: 000000003c02a15f rbx: ffff8300dfb98000 rcx: 0000000000000001
(XEN) rdx: 0000000000000000 rsi: 0000000000000005 rdi: ffff82d0803196ec
(XEN) rbp: ffff82d0802d7eb0 rsp: ffff82d0802d7e30 r8: ffff82d080319700
(XEN) r9: ffff82d080315600 r10: 0000000202746bd9 r11: 0000000000000003
(XEN) r12: 000000003c02a15f r13: 0000000000000000 r14: ffff82d0803196e8
(XEN) r15: 0000000000000001 cr0: 000000008005003b cr4: 00000000000426f0
(XEN) cr3: 00000000df889000 cr2: 00000000000000c8
(XEN) ds: 0000 es: 0000 fs: 0000 gs: 0000 ss: 0000 cs: e008
(XEN) Xen stack trace from rsp=ffff82d0802d7e30:
(XEN) ffff82d0802d7e60 ffff82d080319700 00000000002d7e60 ffff82d0803196e0
(XEN) ffff82d08012a344 ffff82d080319880 ffff82d0802d7eb0 0000000000000000
(XEN) 000000003c02a17d 0000000000040000 0000000000000001 ffff82d0802eff00
(XEN) ffff82d0802eff00 ffff82d0802d0000 ffffffffffffffff ffff83000008efb0
(XEN) ffff82d0802d7ee0 ffff82d080129cb9 ffff82d0802d0000 ffff82d0802d0000
(XEN) 0000000000000001 ffff82d08027ab60 ffff82d0802d7ef0 ffff82d080129d12
(XEN) ffff82d0802d7f10 ffff82d080160355 00000000df890000 0000000000040000
(XEN) ffff82d0802d7ef0 0000000000000000 0000000000000000 0000000000000000
(XEN) 0000000000000000 0000000000000000 0000000000000000 0000000000000000
(XEN) 0000000000000000 0000000000000000 0000000000000000 0000000000000000
(XEN) 0000000000000000 0000000000000000 0000000000000000 0000000000000000
(XEN) 0000000000000000 0000000000000000 0000000000000000 0000000000000000
(XEN) 0000000000000000 0000000000000000 0000000000000000 0000000000000000
(XEN) 0000000000000000 0000000000000000 0000000000000000 ffff8300dfb98000
(XEN) 0000000000000000 0000000000000000
(XEN) Xen call trace:
(XEN) [<ffff82d080126dbe>] schedule+0x408/0x5df
(XEN) [<ffff82d080129cb9>] __do_softirq+0x81/0x8c
(XEN) [<ffff82d080129d12>] do_softirq+0x13/0x15
(XEN) [<ffff82d080160355>] idle_loop+0x64/0x74
(XEN)
(XEN) Pagetable walk from 00000000000000c8:
(XEN) L4[0x000] = 0000000215507063 ffffffffffffffff
(XEN) L3[0x000] = 0000000215506063 ffffffffffffffff
(XEN) L2[0x000] = 0000000215505063 ffffffffffffffff
(XEN) L1[0x000] = 0000000000000000 ffffffffffffffff
(XEN)
(XEN) ****************************************
(XEN) Panic on CPU 0:
(XEN) FATAL PAGE FAULT
(XEN) [error_code=0000]
(XEN) Faulting linear address: 00000000000000c8
(XEN) ****************************************
(XEN)
(XEN) Reboot in five seconds...
(XEN) Debugging connection not set up.
One more thing, how to setup debugging connection here?
Any suggestion is appreciated. Thank you very much.
Regards,
Idris
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Kernel panic, reboot in 5 seconds
2015-05-14 13:00 Kernel panic, reboot in 5 seconds Mr Idris
@ 2015-05-18 11:00 ` George Dunlap
2015-05-21 13:06 ` Mr Idris
0 siblings, 1 reply; 6+ messages in thread
From: George Dunlap @ 2015-05-18 11:00 UTC (permalink / raw)
To: Mr Idris; +Cc: xen-devel@lists.xen.org
On Thu, May 14, 2015 at 2:00 PM, Mr Idris <mr@idris.web.id> wrote:
> I'm trying to create cpu scheduler on xen 4.4.1 using debian 7 which
> inspired by arinc653 scheduler. When i use it, it gives me something
> like kernel panic and reboot in 5 secs before go in to the system. I
> don't know how to procced to fix the errors, Here is some debug
> errors :
>
> (XEN) Debugging connection not set up.
> (XEN) ----[ Xen-4.4.1 x86_64 debug=y Not tainted ]----
> (XEN) CPU: 0
> (XEN) RIP: e008:[<ffff82d080126dbe>] schedule+0x408/0x5df
> (XEN) RFLAGS: 0000000000010006 CONTEXT: hypervisor
> (XEN) rax: 000000003c02a15f rbx: ffff8300dfb98000 rcx: 0000000000000001
> (XEN) rdx: 0000000000000000 rsi: 0000000000000005 rdi: ffff82d0803196ec
> (XEN) rbp: ffff82d0802d7eb0 rsp: ffff82d0802d7e30 r8: ffff82d080319700
> (XEN) r9: ffff82d080315600 r10: 0000000202746bd9 r11: 0000000000000003
> (XEN) r12: 000000003c02a15f r13: 0000000000000000 r14: ffff82d0803196e8
> (XEN) r15: 0000000000000001 cr0: 000000008005003b cr4: 00000000000426f0
> (XEN) cr3: 00000000df889000 cr2: 00000000000000c8
> (XEN) ds: 0000 es: 0000 fs: 0000 gs: 0000 ss: 0000 cs: e008
> (XEN) Xen stack trace from rsp=ffff82d0802d7e30:
> (XEN) ffff82d0802d7e60 ffff82d080319700 00000000002d7e60 ffff82d0803196e0
> (XEN) ffff82d08012a344 ffff82d080319880 ffff82d0802d7eb0 0000000000000000
> (XEN) 000000003c02a17d 0000000000040000 0000000000000001 ffff82d0802eff00
> (XEN) ffff82d0802eff00 ffff82d0802d0000 ffffffffffffffff ffff83000008efb0
> (XEN) ffff82d0802d7ee0 ffff82d080129cb9 ffff82d0802d0000 ffff82d0802d0000
> (XEN) 0000000000000001 ffff82d08027ab60 ffff82d0802d7ef0 ffff82d080129d12
> (XEN) ffff82d0802d7f10 ffff82d080160355 00000000df890000 0000000000040000
> (XEN) ffff82d0802d7ef0 0000000000000000 0000000000000000 0000000000000000
> (XEN) 0000000000000000 0000000000000000 0000000000000000 0000000000000000
> (XEN) 0000000000000000 0000000000000000 0000000000000000 0000000000000000
> (XEN) 0000000000000000 0000000000000000 0000000000000000 0000000000000000
> (XEN) 0000000000000000 0000000000000000 0000000000000000 0000000000000000
> (XEN) 0000000000000000 0000000000000000 0000000000000000 0000000000000000
> (XEN) 0000000000000000 0000000000000000 0000000000000000 ffff8300dfb98000
> (XEN) 0000000000000000 0000000000000000
> (XEN) Xen call trace:
> (XEN) [<ffff82d080126dbe>] schedule+0x408/0x5df
> (XEN) [<ffff82d080129cb9>] __do_softirq+0x81/0x8c
> (XEN) [<ffff82d080129d12>] do_softirq+0x13/0x15
> (XEN) [<ffff82d080160355>] idle_loop+0x64/0x74
> (XEN)
> (XEN) Pagetable walk from 00000000000000c8:
> (XEN) L4[0x000] = 0000000215507063 ffffffffffffffff
> (XEN) L3[0x000] = 0000000215506063 ffffffffffffffff
> (XEN) L2[0x000] = 0000000215505063 ffffffffffffffff
> (XEN) L1[0x000] = 0000000000000000 ffffffffffffffff
> (XEN)
> (XEN) ****************************************
> (XEN) Panic on CPU 0:
> (XEN) FATAL PAGE FAULT
> (XEN) [error_code=0000]
> (XEN) Faulting linear address: 00000000000000c8
> (XEN) ****************************************
> (XEN)
> (XEN) Reboot in five seconds...
> (XEN) Debugging connection not set up.
Fundamentally, the bug you're getting is that you're dereferencing a
null pointer, probably into a struct (that's the "Faulting linear
address" -- 0xc8 will be the offset into the struct).
A full serial log from boot would be more helpful to figure out where
that dereference might be happening.
> One more thing, how to setup debugging connection here?
> Any suggestion is appreciated. Thank you very much.
I don't use the debugger personally; I tend to use printk. It's also
useful to comb through the changes you've made to the code to make
sure you've set all the pointers which need to be set.
-George
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Kernel panic, reboot in 5 seconds
2015-05-18 11:00 ` George Dunlap
@ 2015-05-21 13:06 ` Mr Idris
2015-05-21 14:17 ` Dario Faggioli
0 siblings, 1 reply; 6+ messages in thread
From: Mr Idris @ 2015-05-21 13:06 UTC (permalink / raw)
To: George Dunlap; +Cc: xen-devel@lists.xen.org
On 5/18/15, George Dunlap <George.Dunlap@eu.citrix.com> wrote:
> On Thu, May 14, 2015 at 2:00 PM, Mr Idris <mr@idris.web.id> wrote:
>> I'm trying to create cpu scheduler on xen 4.4.1 using debian 7 which
>> inspired by arinc653 scheduler. When i use it, it gives me something
>> like kernel panic and reboot in 5 secs before go in to the system. I
>> don't know how to procced to fix the errors, Here is some debug
>> errors :
>>
>> (XEN) Debugging connection not set up.
>> (XEN) ----[ Xen-4.4.1 x86_64 debug=y Not tainted ]----
>> (XEN) CPU: 0
>> (XEN) RIP: e008:[<ffff82d080126dbe>] schedule+0x408/0x5df
>> (XEN) RFLAGS: 0000000000010006 CONTEXT: hypervisor
>> (XEN) rax: 000000003c02a15f rbx: ffff8300dfb98000 rcx:
>> 0000000000000001
>> (XEN) rdx: 0000000000000000 rsi: 0000000000000005 rdi:
>> ffff82d0803196ec
>> (XEN) rbp: ffff82d0802d7eb0 rsp: ffff82d0802d7e30 r8:
>> ffff82d080319700
>> (XEN) r9: ffff82d080315600 r10: 0000000202746bd9 r11:
>> 0000000000000003
>> (XEN) r12: 000000003c02a15f r13: 0000000000000000 r14:
>> ffff82d0803196e8
>> (XEN) r15: 0000000000000001 cr0: 000000008005003b cr4:
>> 00000000000426f0
>> (XEN) cr3: 00000000df889000 cr2: 00000000000000c8
>> (XEN) ds: 0000 es: 0000 fs: 0000 gs: 0000 ss: 0000 cs: e008
>> (XEN) Xen stack trace from rsp=ffff82d0802d7e30:
>> (XEN) ffff82d0802d7e60 ffff82d080319700 00000000002d7e60
>> ffff82d0803196e0
>> (XEN) ffff82d08012a344 ffff82d080319880 ffff82d0802d7eb0
>> 0000000000000000
>> (XEN) 000000003c02a17d 0000000000040000 0000000000000001
>> ffff82d0802eff00
>> (XEN) ffff82d0802eff00 ffff82d0802d0000 ffffffffffffffff
>> ffff83000008efb0
>> (XEN) ffff82d0802d7ee0 ffff82d080129cb9 ffff82d0802d0000
>> ffff82d0802d0000
>> (XEN) 0000000000000001 ffff82d08027ab60 ffff82d0802d7ef0
>> ffff82d080129d12
>> (XEN) ffff82d0802d7f10 ffff82d080160355 00000000df890000
>> 0000000000040000
>> (XEN) ffff82d0802d7ef0 0000000000000000 0000000000000000
>> 0000000000000000
>> (XEN) 0000000000000000 0000000000000000 0000000000000000
>> 0000000000000000
>> (XEN) 0000000000000000 0000000000000000 0000000000000000
>> 0000000000000000
>> (XEN) 0000000000000000 0000000000000000 0000000000000000
>> 0000000000000000
>> (XEN) 0000000000000000 0000000000000000 0000000000000000
>> 0000000000000000
>> (XEN) 0000000000000000 0000000000000000 0000000000000000
>> 0000000000000000
>> (XEN) 0000000000000000 0000000000000000 0000000000000000
>> ffff8300dfb98000
>> (XEN) 0000000000000000 0000000000000000
>> (XEN) Xen call trace:
>> (XEN) [<ffff82d080126dbe>] schedule+0x408/0x5df
>> (XEN) [<ffff82d080129cb9>] __do_softirq+0x81/0x8c
>> (XEN) [<ffff82d080129d12>] do_softirq+0x13/0x15
>> (XEN) [<ffff82d080160355>] idle_loop+0x64/0x74
>> (XEN)
>> (XEN) Pagetable walk from 00000000000000c8:
>> (XEN) L4[0x000] = 0000000215507063 ffffffffffffffff
>> (XEN) L3[0x000] = 0000000215506063 ffffffffffffffff
>> (XEN) L2[0x000] = 0000000215505063 ffffffffffffffff
>> (XEN) L1[0x000] = 0000000000000000 ffffffffffffffff
>> (XEN)
>> (XEN) ****************************************
>> (XEN) Panic on CPU 0:
>> (XEN) FATAL PAGE FAULT
>> (XEN) [error_code=0000]
>> (XEN) Faulting linear address: 00000000000000c8
>> (XEN) ****************************************
>> (XEN)
>> (XEN) Reboot in five seconds...
>> (XEN) Debugging connection not set up.
>
> Fundamentally, the bug you're getting is that you're dereferencing a
> null pointer, probably into a struct (that's the "Faulting linear
> address" -- 0xc8 will be the offset into the struct).
>
> A full serial log from boot would be more helpful to figure out where
> that dereference might be happening.
>
>> One more thing, how to setup debugging connection here?
>> Any suggestion is appreciated. Thank you very much.
>
> I don't use the debugger personally; I tend to use printk. It's also
> useful to comb through the changes you've made to the code to make
> sure you've set all the pointers which need to be set.
>
> -George
>
Thanks for the information.
I'm still confuse with the do_schedule() on each scheduler in xen.
There are 2 parameters that i think the most important to build simple
scheduler, ret.time and ret.task.
ret.time is the time that is set for the VCPU, anyVCPU which run.
ret.task is the context or domain that should be run/scheduled. Am i correct?
Or where can i set which domain/process/context should run first?
Regards,
Idris
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Kernel panic, reboot in 5 seconds
2015-05-21 13:06 ` Mr Idris
@ 2015-05-21 14:17 ` Dario Faggioli
2015-05-25 13:41 ` Mr Idris
0 siblings, 1 reply; 6+ messages in thread
From: Dario Faggioli @ 2015-05-21 14:17 UTC (permalink / raw)
To: Mr Idris; +Cc: George Dunlap, xen-devel@lists.xen.org
[-- Attachment #1.1: Type: text/plain, Size: 2812 bytes --]
On Thu, 2015-05-21 at 15:06 +0200, Mr Idris wrote:
> On 5/18/15, George Dunlap <George.Dunlap@eu.citrix.com> wrote:
> >> (XEN) Xen call trace:
> >> (XEN) [<ffff82d080126dbe>] schedule+0x408/0x5df
> >> (XEN) [<ffff82d080129cb9>] __do_softirq+0x81/0x8c
> >> (XEN) [<ffff82d080129d12>] do_softirq+0x13/0x15
> >> (XEN) [<ffff82d080160355>] idle_loop+0x64/0x74
> >> (XEN)
> >> (XEN) Pagetable walk from 00000000000000c8:
> >> (XEN) L4[0x000] = 0000000215507063 ffffffffffffffff
> >> (XEN) L3[0x000] = 0000000215506063 ffffffffffffffff
> >> (XEN) L2[0x000] = 0000000215505063 ffffffffffffffff
> >> (XEN) L1[0x000] = 0000000000000000 ffffffffffffffff
> >> (XEN)
> >> (XEN) ****************************************
> >> (XEN) Panic on CPU 0:
> >> (XEN) FATAL PAGE FAULT
> >> (XEN) [error_code=0000]
> >> (XEN) Faulting linear address: 00000000000000c8
> >> (XEN) ****************************************
> >> (XEN)
> >> (XEN) Reboot in five seconds...
> >> (XEN) Debugging connection not set up.
> >
> > Fundamentally, the bug you're getting is that you're dereferencing a
> > null pointer, probably into a struct (that's the "Faulting linear
> > address" -- 0xc8 will be the offset into the struct).
> Thanks for the information.
>
> I'm still confuse with the do_schedule() on each scheduler in xen.
> There are 2 parameters that i think the most important to build simple
> scheduler, ret.time and ret.task.
>
ret.migrated as well, as per:
struct task_slice {
struct vcpu *task;
s_time_t time;
bool_t migrated;
};
in xen/include/xen/sched-if.h.
It's important for decidine whether we need to call sched_move_irqs().
> ret.time is the time that is set for the VCPU, anyVCPU which run.
>
I can't parse this sentence (or, at least, I can't be sure I'm parsing
it right).
ret.time is the next time instant you want a timer to fire, as you can
see right below the call do sched->do_schedule(), in schedule.c. That
timer, when firing, will cause the scheduler to run again, as it also
can be easily seen in schedule.c, checking out occurrences of s_timer
and s_timer_fn.
> ret.task is the context or domain that should be run/scheduled. Am i correct?
>
It's the vcpu to be run next, yes.
> Or where can i set which domain/process/context should run first?
>
I'm not sure I'm getting this either... IIUIC, that is what you should
do in your implementation of the do_schedule hook, for your scheduler.
I mean, Credit does it in csched_schedule(), Credit2 in
csched2_schedule(), RTDS in rt_schedule(), ARINC653 in
a653sched_do_schedule().
But maybe I'm missing what you mean with "should run *first*".
BTW, what's the purpose of the new scheduler you're working on, if I can
ask?
Regards,
Dario
[-- Attachment #1.2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 181 bytes --]
[-- Attachment #2: Type: text/plain, Size: 126 bytes --]
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Kernel panic, reboot in 5 seconds
2015-05-21 14:17 ` Dario Faggioli
@ 2015-05-25 13:41 ` Mr Idris
2015-05-26 11:53 ` Dario Faggioli
0 siblings, 1 reply; 6+ messages in thread
From: Mr Idris @ 2015-05-25 13:41 UTC (permalink / raw)
To: Dario Faggioli; +Cc: George Dunlap, xen-devel@lists.xen.org
On 5/21/15, Dario Faggioli <dario.faggioli@citrix.com> wrote:
> On Thu, 2015-05-21 at 15:06 +0200, Mr Idris wrote:
>> On 5/18/15, George Dunlap <George.Dunlap@eu.citrix.com> wrote:
>> >
>> > Fundamentally, the bug you're getting is that you're dereferencing a
>> > null pointer, probably into a struct (that's the "Faulting linear
>> > address" -- 0xc8 will be the offset into the struct).
>
>> Thanks for the information.
>>
>> I'm still confuse with the do_schedule() on each scheduler in xen.
>> There are 2 parameters that i think the most important to build simple
>> scheduler, ret.time and ret.task.
>>
> ret.migrated as well, as per:
>
> struct task_slice {
> struct vcpu *task;
> s_time_t time;
> bool_t migrated;
> };
>
> in xen/include/xen/sched-if.h.
>
> It's important for decidine whether we need to call sched_move_irqs().
>
>> ret.time is the time that is set for the VCPU, anyVCPU which run.
>>
> I can't parse this sentence (or, at least, I can't be sure I'm parsing
> it right).
>
> ret.time is the next time instant you want a timer to fire, as you can
> see right below the call do sched->do_schedule(), in schedule.c. That
> timer, when firing, will cause the scheduler to run again, as it also
> can be easily seen in schedule.c, checking out occurrences of s_timer
> and s_timer_fn.
>
Ok, i thought before ret.time is the time for VCPU to run. But
ret.time is time to call again do_schedule() which doing schedule for
VCPU time and domain. Right?
>> ret.task is the context or domain that should be run/scheduled. Am i
>> correct?
>>
> It's the vcpu to be run next, yes.
>
>> Or where can i set which domain/process/context should run first?
>>
> I'm not sure I'm getting this either... IIUIC, that is what you should
> do in your implementation of the do_schedule hook, for your scheduler.
>
So ret.task set which VCPU to be run. What i am looking for where is
the parameter for deciding which domain is run on that VCPU? Anydomain
whether dom0 or domU.
> I mean, Credit does it in csched_schedule(), Credit2 in
> csched2_schedule(), RTDS in rt_schedule(), ARINC653 in
> a653sched_do_schedule().
>
> But maybe I'm missing what you mean with "should run *first*".
>
> BTW, what's the purpose of the new scheduler you're working on, if I can
> ask?
>
I want to create scheduler like round robin with priorities. Dom0 has
higher priority, so always scheduled between domU.
> Regards,
> Dario
>
Thanks,
Idris
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Kernel panic, reboot in 5 seconds
2015-05-25 13:41 ` Mr Idris
@ 2015-05-26 11:53 ` Dario Faggioli
0 siblings, 0 replies; 6+ messages in thread
From: Dario Faggioli @ 2015-05-26 11:53 UTC (permalink / raw)
To: Mr Idris; +Cc: George Dunlap, xen-devel@lists.xen.org
[-- Attachment #1.1: Type: text/plain, Size: 2804 bytes --]
On Mon, 2015-05-25 at 15:41 +0200, Mr Idris wrote:
> On 5/21/15, Dario Faggioli <dario.faggioli@citrix.com> wrote:
> > ret.time is the next time instant you want a timer to fire, as you can
> > see right below the call do sched->do_schedule(), in schedule.c. That
> > timer, when firing, will cause the scheduler to run again, as it also
> > can be easily seen in schedule.c, checking out occurrences of s_timer
> > and s_timer_fn.
> >
>
> Ok, i thought before ret.time is the time for VCPU to run. But
> ret.time is time to call again do_schedule() which doing schedule for
> VCPU time and domain. Right?
>
I'm probably still missing something.
If ret.time is > 0, a timer will
fire at NOW()+ret.time, and it will raise the SCHEDULE_SOFTIRQ, which in
turn will 'call' schedule().
Whether or not this will be the runtime (of an instance) of a particular
vCPU (e.g., the one being scheduled as the result of the current call to
schedule()), it depends on how the scheduler is implemented and on
whether there is something else that raises the softirq and interrupt
the said vCPU before NOW()+ret.time (a wakeup of another vCPU, a yield
of the running vCPU, etc.)
> >> ret.task is the context or domain that should be run/scheduled. Am i
> >> correct?
> >>
> > It's the vcpu to be run next, yes.
> >
> >> Or where can i set which domain/process/context should run first?
> >>
> > I'm not sure I'm getting this either... IIUIC, that is what you should
> > do in your implementation of the do_schedule hook, for your scheduler.
> >
>
> So ret.task set which VCPU to be run. What i am looking for where is
> the parameter for deciding which domain is run on that VCPU? Anydomain
> whether dom0 or domU.
>
What do you mean "which domain is run on that VCPU"? A vCPU belongs to a
domain, so, when running a particular vCPU on a pCPU, you're giving the
domain it belongs to a chance to execute... Do you perhaps refer to
physical CPUs (often referred to as pCPUs or PCPUs)? But then, if yes, I
don't understand the question: you already found it, it's there in
schedul()-->do_schedule().
> > BTW, what's the purpose of the new scheduler you're working on, if I can
> > ask?
> >
>
> I want to create scheduler like round robin with priorities. Dom0 has
> higher priority, so always scheduled between domU.
>
And if I can continue asking, what would be the use case? Where and how
do you think this would work better than the schedulers we have in Xen
already?
Regards,
Dario
--
<<This happens because I choose it to happen!>> (Raistlin Majere)
-----------------------------------------------------------------
Dario Faggioli, Ph.D, http://about.me/dario.faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)
[-- Attachment #1.2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 181 bytes --]
[-- Attachment #2: Type: text/plain, Size: 126 bytes --]
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2015-05-26 11:53 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2015-05-14 13:00 Kernel panic, reboot in 5 seconds Mr Idris
2015-05-18 11:00 ` George Dunlap
2015-05-21 13:06 ` Mr Idris
2015-05-21 14:17 ` Dario Faggioli
2015-05-25 13:41 ` Mr Idris
2015-05-26 11:53 ` Dario Faggioli
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.