Xen progress

I think I have the FBT provider working now on a Xen guest. As usual,
one has to do "everything right", and "nearly-right" is not good enough.

Unfortunately, knowing what "right" is, is difficult!

BTW, I want to complain about google.com. Here is a fascinating
in depth article, written by authors of VMware, which gently leads
you through how VMware works and VM monitors in general.

web.mit.edu/6.033/www/papers/agesen.pdf

My complaint is that google wraps all links, so you cant just take
the URL of a page you jumped to, but need to copy the link from
the results page (which is not in a form that is an http embeddable link).

The article above hinted at a problem I was seeing in getting FBT
to work *reliably*. FBT uses the INT3 and INT1 interrupt traps.
I have had to rework the interrupt handles to be CONFIG_PARAVIRT
compliant (and need to rework again so that the code works on a
non-CONFIG_PARAVIRT kernel). Anyhow, a dtrace like:

$ dtrace -n fbt::sys_*:

would run for about 30-60,000 syscalls, and then a problem would
arise. When doing FBT, we replace the instruction with a breakpoint
instruction (INT3), single step the replaced instruction, and then
resume execution.

What appears to happen is that occasionally the single-step trap would
not fire. The copied instruction, which we single stepped, would
continue execution after the copied instruction..resulting in a
kernel page_fault. Now this is strange, because in the
copy-buffer, we have:

original-instruction, nop

The nop should never be executed because of the single-step mode;
placing a NOP after the valid instruction seems like a good practise,
(rather than random junk) because otherwise the CPU may fetch ahead
and try to decode a junk instruction, even if it is not executed.

I tried the following:

original-instruction, nop, nop

Two nop's after the instruction, and it ran much better; the first
time, it got to nearly 1,000,000 traces; I then killed it, removed
some of my debug, and ran again. Whilst writing this article, it
got to about 750,000 traces, but the same thing happened. Heres
the dump from the kernel:

[26881.316402] Call Trace:
[26881.316412]  [<ffffffff81664a82>] ? system_call_fastpath+0x16/0x1b
[26881.316417] Code: ff ff ff ff 00 00 00 00 00 10 00 81 ff ff ff ff 
00 10 00 81 ff ff ff ff 55 6e 10 00 03 8e 03 a0 ff ff ff ff 00 00 
00 00 55 90 90 <00> 00 ...

Opcode 55 is "PUSH %RBP"; NOP is 0x90. The instruction after the second
0x90, is an instruction which causes a kernel page fault. So, the
cpu went marching on ahead and fell over...despite the trap
flag being set.

At the moment, this is weird, and it looks like Xen is not honoring
an IRET (or the hypervisor call equivalent) everytime, and ignoring
the single step mode.

Now off to do more research ... maybe its a known bug in Xen,
or maybe I have honored one of the rules (but the "rules" arent
written down anywhere :-) ).




Post created by CRiSP v11.0.13a-b6462