which states that launching qemu with option "-d
cpu,exec,in_asm" creates a trace log in /tmp/qemu.log which can be
helpful when qemu crashes.
I hope this will be more helpful than my previous
post ;-)
-- Best regards, Hervé Peignelin.
Youren Shen <shenyouren@xxxxxxxxx> a écrit sur
18/08/2014 16:11:57 :
> De : Youren Shen <shenyouren@xxxxxxxxx> > A : pok@xxxxxxxxxxxxxxxxxxx > Date : 18/08/2014 16:12 > Objet : Re: [pok] The paravirtuailization in
POK for RTEMS. >
> Hi, Herve: >
> Thank you for your scrupulous care for my work. >
> I‘m sorry this project is big and the schedule is tight, so I am
in
> some hurry. My work flow in this summer is: > figure out the problem-> learned or found
an approaching->make a
> brief design->write prototypical code->write documents and discuss
> with mentor->debug. >
> This bug has been fixed in this commit[1]. But I did not update the
> blog in time. I have checked every line I can single step to in GDB.
> And now the main problem is how to locate the crash point. Is there
> a way which will generate a core file when the qemu crash? >
> Thank you very much. > [1]. https://github.com/HuaiYuSched/pok-1/commit/
> 4dad3c0eabda14440a7cac24548220f4b75f0f4c >
> On Mon, Aug 18, 2014 at 6:34 PM, <Herve.Peignelin@xxxxxxxxxxxxxxxxxxx>
wrote: > Hello,
>
> I have followed your link, and in the code given in this page, there
> is an obvious bug in do_IRQ_guest() function.
> In effect, your inner loop (on "j" index) seems to be useless,
since
> you don't use "j" in your code.
> After a second check, I think that you used "i" where you
intended
> to use "j" in your code, so for exemple:
> if(v->arch.irqdesc[i].vector == vector)
> should be written
> if(v->arch.irqdesc[j].vector == vector)
> instead. (Two others indexes follows)
>
> Theoretically, this bug should have no side effect while you have
16
> partitions or less, other than the interrupt virtualization has
> little chance to work. From 17 partitions and more, you have an
> array overflow, since you're indexing irqdesc[] with the partition
> number (i) instead of its intended range (j).
> So, I don't think it explains your crash problem, but I hope this
> will help you in your debug.
>
> --
> Best regards,
> Hervé Peignelin.
>
>
>
>
> De : Youren Shen <shenyouren@xxxxxxxxx>
> A : pok@xxxxxxxxxxxxxxxxxxx, Philipp Eppelt
<
> philipp.eppelt@xxxxxxxxxxxxxxxxxxxxx>, Gedare Bloom <gedare@xxxxxxxxx>
> Date : 17/08/2014 16:32
> Objet : [pok] The paravirtuailization in
POK for RTEMS.
>
>
>
> Hi, everyone:
>
> I''m a student for Google Summer of Code. this year. My project, as
> I described before, is adapt the POK as an hypervisor to run the RTEMS.
> Now I have make some changes in POK kernel, make a pull request
in
> github. And I have write a explanation in this wiki page[1].
>
> But I'd like to give an brief introduction.
> When an interrupt occurs, like time interrupt, we will mask it in
> vCPU. when a partition resumes it will check the vCPU, if there is
> an interrupt pending on vCPU, then store the interrupt frame and
> change eip in the stack of current interrupt as interrupt handler
in
> user spcae. After interrupt handler, it will invoke an hypercall
> (syscall) do_iret. this will check whether there are still some
> interrupt pending on vCPU. If no, then restore the interrupt frame
> and return to normal program execution.
>
> Unlucky, this mechanism is not working now. I have spent lots of
> time to debug it. > The pok will crash when I disable all breakpoint
and continue it.
> But if I running step by step, the kernel won't crash. Also the iret
> can't be tracked(to execute iret once will not cause the crash of
> POK). I can't locate the reason of this problem, can you give me
> some suggestions? > Thank you very much. >
> [1]. http://www.rtems.org/wiki/index.php/GSOC_2014_-
> _Paravirtualization_of_RTEMS
> --
> Best Regards.
> Youren Shen. >