Hey all,
Attached is a new patch. This one *REPLACES* the
old patch.
Ulrich Weigand wrote:
> 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 ...).
Done. I use the VIF and VIP flags in eflags in order to
do this, like described in the Intel manual part 3,
paragraph 15.4. As a matter of fact, turning on PVM
should work fine now (I didn't try it), but it is
emulated as well.
Of course, you were right about trapping back to the user
on STI -- I didn't read your previous email correctly ;).
Sorry about that.
> 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 :-/).
I didn't change this, yet... still need to think about
how it is best to do this.
> > - 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 ...
Hmm... you're right again. I seem to remember compiling
with ./configure.linux and then not getting debug info,
but that has apparently been fixed. I removed this in
the new patch.
> > - 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.
Removed.
> > - 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.
Removed.
> > - 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.)
Okay, I implemented a solution. It's not perfect but it'll
do for now. It can be changed later.
-- Ramon
fmw.new.patch.gz
