Re: [Xen-devel] Kernel panic, reboot in 5 seconds

[Dario Faggioli <dario.faggioli@xxxxxxxxxx>]

On Thu, 2015-05-21 at 15:06 +0200, Mr Idris wrote:
> On 5/18/15, George Dunlap <George.Dunlap@xxxxxxxxxxxxx> 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: signature.asc
Description: This is a digitally signed message part

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel