Ulrich Weigand wrote:
>
> 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 ...
Uh... sure. But that's not CLI/STI ;)
Perhaps it's better if in stead of making vm_vif
a global variable in the userspace monitor, it
is part of context.eflags, which is set in the
kernel module... what do you think ?
> 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.
Kevin's working on that ;).
> 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 ...).
Well, not really -- after all, whether IF is or is
not set is only used when there is a pending event
from the PIC. In order to forward that, the userspace
monitor needs to be invoked anyway (signal?) so that
shouldn't be a problem.
There should be a shared flag in context that is used
for this purpose, IMO.
> Another point that isn't quite correct is that STI doesn't enable
> interrupts until after the instruction *following* the STI.
Really ? I never knew that... sounds like RISC
delay slots..
> This can probably be fixed by horsing around with the trap flag ...
Yes. I'll have to think about that one ;)
Tell you what, don't yet commit my cli/sti hack, I'll
create a better fix today.
> > - Fixed configure.linux to compile with debug info
>
> Isn't everything compiled with debug info anyway?
Not on my box... perhaps you have different environemnt
variable settings ?
I often use GDB to debug just about any part of freemware
except the kernel module, so it's nice if it's compiled
with debug information..
> > - 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.
OK.
> 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. ]
Uh... ok. Will you be working on that, then ?
> > - 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'll add this.
> [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.
Ok.
> > - 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 ;-)
I have paging code right here, ready to be plugged
into the preemptive kernel (I originally stripped
the paging code from the preemptive kernel, to make
things easier ;)). Perhaps that's an easier test.
-- Ramon
