Re: [pok] The paravirtuailization in POK for RTEMS.

[Youren Shen <shenyouren@xxxxxxxxx>]

Hi, Hervé:

Thank you for your suggestion.

The -d option has been already set on POK example.mk. There must be a bug in my qemu version before, which cause no information output. After I update my qemu then it has some output in console, but not the log file now.

However I'm confused by the content of the output, I think I need to consult the qemu community.

Thank you very much for your help :).

On Tue, Aug 19, 2014 at 5:16 PM, <Herve.Peignelin@xxxxxxxxxxxxxxxxxxx> wrote:

Hello Youren,

I googled "qemu crash debug" and find some tracks...

In a discussion about similar problems with qemu here:
        http://forum.osdev.org/viewtopic.php?f=1&t=27302

They give a link to a helpful page:
        http://www.droid-developers.org/wiki/QEMU

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.
>

>
> --
> Best Regards.
> Youren Shen.

--

Best Regards.

Youren Shen.