Ramon van Handel wrote:
> - Implemented CLI/STI (this was childishly simple...
> I hope I didn't overlook anything !)
Well, just that the IF can be set via other means as well, e.g. POPF
or IRET ...
> - Fixed preemptive kernel to enable interrupts
... which is what the preemptive kernel did to enable interrupts ;-)
Of course, this is rather difficult to fix, as POPF doesn't trap,
but simply silently ignores the new IF value if running at CPL > IOPL.
Unless someone has a really clever idea, this would seem to require
full-blown instruction scanning.
IRET does trap, however, so we could at least fix the preemptive
kernel instead of modifying it. This would appear to require the
IF handling to be moved into kernel space, which raises other problems
(user space has to signal to the kernel that INTR is asserted so that
the kernel drops back to user space as soon as IF gets set ...).
Another point that isn't quite correct is that STI doesn't enable
interrupts until after the instruction *following* the STI. Note that
guests might well rely on that fact (in fact, freemware itself relies
on it, so if we ever want to run freemware under itself, we have to
get that right :-/).
This can probably be fixed by horsing around with the trap flag ...
> - Fixed configure.linux to compile with debug info
Isn't everything compiled with debug info anyway? I'd rather like
to *remove* stuff from configure.linux, especially if it isn't
really Linux specific ...
> - 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 ?
I guess so, yes.
> - 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).
Ah, there are still some cases where 'return 0' indicates that
some special case is not yet implemented correctly by the emulation
layer. Furthermore, you can't always simply use emulate_int,
first of all because this doesn't create a error code (needed
for certain exceptions), and second because maybe you need to
generate a *different* exception -- the exception generated by
the processor is the one appropriate for ring-3, while the guest
might think it is running at ring-0, which means that the instruction
should actually fail due to a different reason.
I had been planning on
- modify emulate_int to push an optional error code
- have the various cases in emulate() raise the correct exception
(as expected by the guest) in-place
- use a 'return 0' only to signal emulation failure (unexpected
situations, not-yet-implemented ...)
[ B.t.w. I'm not really convinced that simply calling emulate_int
as a default action in handle_fault is the right thing to do,
because of the two problems mentioned above. ]
> - 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 ?
Probably.
> - 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 ?
You shouldn't fiddle with context.event_info inside plugin_emulate_int
(did I mention that I don't like global variables ;-/). Instead, pass
the flag that an interrupt is supposed to be raised up the caller chain
until it reaches the main loop. This can cope with that situation just
fine; the reflected interrupt takes precedence over a PIC interrupt.
(And it also ignores the IF setting.)
[snip]
> - 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.)
I don't think it's necessary to do this right now; until Linux runs
fine in text mode, there's no use in trying to do graphics modes ...
Anyway, this will interfere with the paging layer, so we should have
paging support in place first.
> - Implement paging support (movl %eax,%cr3; etc.)
Yup, that's what I wanted to work on next. (Unfortunately, for the
next two weeks or so I won't have much time due to upcoming exams.)
As a small task I wanted to implement a Linux loader that sets up
the data structure used to initialize the kernel, so that we can
test paging with a real OS ;-)
Bye,
Ulrich
--
Ulrich Weigand,
IMMD 1, Universitaet Erlangen-Nuernberg,
Martensstr. 3, D-91058 Erlangen, Phone: +49 9131 85-27688
