On Thu, 22 Dec 2011, Gabe Black wrote:
On 12/21/11 23:30, Nilay Vaish wrote:
On Mon, 5 Dec 2011, Gabe Black wrote:
I'm fairly confident that's what's going on. The stack address is user
space and the instruction pointer is in kernel space. The page fault is
from near the ip, and the error code is 15 which means, if I'm not
mistaken, a permission problem on fetch. You can't easily fix the
problem, but if you want to get started the first step would be to clean
up the squashing mechanisms in O3 like I brought up in that email a
while ago. The real problem is that squashing doesn't always preserve
enough state (the macroop instance specifically) in all situations, and
that the squashing stuff is too ad-hoc and all over the place to really
fix it correctly and know that it's correct. I'd thought I fixed it
before when I fixed one particular squash path, but obviously I didn't
get it all.
Gabe, the instruction pointed to by the rip is SYSRET_TO_64. The micro
code for this instrution does not contain any branch. How is it
possible for the O3 bug to show up in this case? In your example using
iret, the problem was that fetch had to re-fetch the macroop from a
kernel page after the mode has been changed. For SYSRET as well the
mode will be change. But since there is no branch prediction, how will
this particular bug manifest it self?
Thanks
Nilay
_______________________________________________
gem5-dev mailing list
[email protected]
http://m5sim.org/mailman/listinfo/gem5-dev
I haven't gone to look at the microcode again, but how would a system
call return instruction work without branches?
Gabe, neither the microcode in gem5, nor the pseudo code given in Intel's
instruction manual use branches. EFLAGS, CPL, CS, SS and RIP registers are
set. There are no checks as such on privilege level or any thing else.
--
Nilay
_______________________________________________
gem5-dev mailing list
[email protected]
http://m5sim.org/mailman/listinfo/gem5-dev
