Hey ho everyone,
Here's another patch. Summary of changes:
- Added interrupt interception to kernel module
(as far as I've been able to test it, it works)
- Added interrupt interception interface for plugins
- Changed ICE plugin to use interrupt interception
- Fixed little glitch in freemware.c that caused
GDB to report weird information when the ICE plugin
just starts up
- Removed the debug_hook callback (obsolete)
- Fixed memory functions in ICE to check for errors
- Fixed the part of the GDB protocol in the ICE that
reports errors to GDB (seems the gdbserver authors
took the PROTOCOL spec rather too literally ;))
- Implemented CLI/STI (this was childishly simple...
I hope I didn't overlook anything !)
- Fixed preemptive kernel to enable interrupts
- Fixed the keyboard scancode map to be standard
QWERTY (more or less; it'll do for a demo-kernel ;))
- Fixed configure.linux to compile with debug info
Glitches / Things I've come across:
- I remember Ulrich saying that iret now works without
the TSS hack. Is this so ? If so, can the
"case 10" in kernel/fault.c be removed ?
- Right now, a "real" GPF (as opposed to a GPF that
makes us emulate instructions) is not virtualised
correctly. Would it be sufficient to forward the
interrupt (using emulate_int) when emulate( context );
in kernel/fault.c returns 0 ? I fear that there is
probably more to it than that, this probably requires
careful thinking (but then, maybe not).
- RET_BECAUSE_EXC return value is now probably pretty
much obsolete, though it is still possible for it
to be generated (in principle). Wouldn't it be best
to remove it altogether ?
- When an interrupt is intercepted, the plugin handling
the intercepted interrupt may choose to "reflect"
the interrupt back into the VM when it's finished.
However, I fear this might get into conflict with the
PIC, if it has interrupts pending at the same time.
Conflicts need to be avoided in the code; does anyone
have an elegant solution ?
- Perhaps the biggest problem: in certain cases, the
ICE doesn't seem to work. The problem is very
reproducible for me, but I have no clue as to where
it comes from. Try this:
- start freemware with the ICE plugin and
the *preemptive* kernel
- hook up to it with GDB
- set a breakpoint on the scheduler() function,
like this: "break scheduler"
- now continue (type "c"). GDB will neatly
break at the beginning of scheduler()
- Now type "n".
What happens to me is that I get a message about an
unaccessible memory location, which GDB attempted
to set a temporary breakpoint at (yes, I had a lot
of fun running gdb gdb ;)). I have no clue why
it tries to access this memory. Typing
"set remotedebug 1" and trying again, you can read
the address off the packet dumps (look for the
"E03" reply). I've searched in vain for this address,
I haven't been able to find out *why* GDB wants to set
a breakpoint there. Perhaps somebody can look at
this ?
One more thing: I'm slightly losing track what
everybody's working on. Perhaps somebody should
maintain a list of who's working on what, and what
needs to be done, etc. I think that would facilitate
development. Currently on my list of "things to be
implemented in the near future" are (this doesn't
necessarily mean I'll implement them, it just means
that they need to get done ;)):
- Implement a general message printing system
for plugins; this will facilitate dumping messages
to a log, or to the GUI, etc.
- Adding vm-core ELF dump support
- Implement memory-mapped I/O (for VGA)
(we need to talk about this; how will we implement
it ? I don't have much experience with VGA
programming so I can't really judge what's needed;
setting the relevant pages read-only and then trapping
back and forth does not seem like an elegant
solution.)
- Implement paging support (movl %eax,%cr3; etc.)
I'll probably work on the first two soon (tomorrow,
or next week) but the last two certainly need more
thought, they are greater undertakings.
PS Kevin, are you still working on scan-before-execute ?
TTYS,
-- Ramon
fmw.new.patch.gz
