A tricky bug that make no sense for me.

[nbdd0121]

In my OS design (64bit), I directly mapped all physical memory to 0xFFFFFF00 00000000, and I mapped memory into process's virtual address area, also.
I met a tricky bug, I let a process run:

Code: Select all

sub $4, %rsp;
repeat:
incl (%rsp);
jmp repeat;

and let kernel display the change of value of (%rsp) every time it switches process.
In bochs and VMware, the values for all processes (ticks are equally allocated) are all the same, that is also my expectation.
In QEMU, the values are different, and 1 process' is 10 times than that of another.
Strange thing happened when I memcpy(rsp-PAGE_SIZE, rsp-PAGE_SIZE, PAGE_SIZE), it should not change anything according to my memcpy implement. But now, QEMU display the exactly same value.
I got really confused (and I am going to be crazy) about the phenomenon I saw.
I think maybe there is a bug about vaddr translation or cache in QEMU?

[doxrobot]

You need to be a little bit more descriptive.

Like,

- What is the frequency of your clock.
- After how many cycles (or time) are you context switching.
- How many logical processors are involved in this scenario.

[nbdd0121]

You need to be a little bit more descriptive.

The problem occurs whatever the frequency is. I tried 100Hz and 10Hz, but the problem still occur. The ticks allocated to process won't influence the problem also. I tried 1 tick, 2ticks, 10ticks, and 20ticks. I only have 1 logical processor.
What's more tricky is when I use gdb with "qemu blah blah -s -S", the problem disappeared.

[thepowersgang]

Well,
1. You don't appear to be clearing the slot before you start incrementing.
2. (this is more a gripe about a too common bad design) Are you tying task switching only to the timer?