Okay, here's an updated patch. I removed all the VIF stuff,
though I do still use mon_eflags&FLG_VIP for that purpose
(I don't see any compelling reasons to change this as the monitor
will never turn VIP/VIF on in the real flags anyway).
I also added a state_flags field to nexus, though it's not yet
in use.
Also, I started implementing STI delay slot functionality (don't
look for the code in the patch, it's not there ;)) and hit a
seemingly major problem --- our event handling structure
is too primitive. Right now, when an event occurs that needs
to be handled by the user-level monitor, we set
context->event_info to whatever the event is and trap back
to the user monitor. However, with things like STI delay slots
and monitor / guest TF functionality, we get the problem that
multiple of such events can occur at the same time, and we
can't really run any more code until ALL events have been
handled.
In order to solve this, we need to have a less primitive form
of event handling. Does anybody have any elegant ideas ?
Personally, I was thinking of implementing an 'event stack'.
When an event occurs, the code where it occurs pushes the
event onto the stack. Later on, when we switch back to
the host part of the (kernel) monitor, the monitor unrolls the
event stack and handles the events one by one.
What do you think ?
-- Ramon
fmw.flag.patch.gz
