>> PS did you ever have a look at my real patch ?
>> Haven't got any feedback yet...
>
>Sorry, I'm a bit short of time at the moment due to upcoming exams ...
Okay.
>Anyway, I'm not sure I completely understand your flag manipulations:
>
>- Why are you differentiating between flags that have a fixed 'real'
> value and those that have a non-fixed 'real' value, but which still
> differs from the guest value?
>
> Wouldn't it be simpler to just have two sorts of flags, those where
> 'real' value is always identical to guest value, and those where
> 'real' value is determined by the monitor (whether it be constant
> or not)?
Uh, I don't quite get your question. I'll try to explain what I did:
In my philosophy, both the guest and the monitor have a separate eflags.
The guest's eflags are the eflags that are set like the guest thinks they
should be (the "virtual" eflags). The monitor flags contain settings that
the monitor uses for virtualisation (like: TF for debugging, or for emulating
STI, VIF/VIP for emulating interrupts, etc.) The "real" flags, as they are
set when the guest code is running, are determined by a "combination" of the
virtual and monitor flags. Example (see also your last question): if either TF
is set in the guest flags, or TF is set in the monitor flags, then TF needs to
be set in the "real" flags. This way, the guest can manipulate TF
independently
of a debugger plugin (---> we need IOCTLs to access the monitor flags).
In order to simplify creating "real" flags from monitor+guest flags, I've
created a set of macros in freemware.h.
As an optimisation, I don't copy the trivial flags (OF, SF, etc.) because
those are the same in monitor and guest anyway --- so I leave them in
context->eflags.
>- What's the point of fiddling around with VIF/VIP any more?
VIP is needed in order to correctly handle a hardware interrupt occuring
while the guest has CLIed.
VIF is handy to use so we can use PVI later on. I guess we could
#ifdef USE_PVI copying IP into VIP, and simply use IF for the rest ---
I'll change that this weekend.
> I mean, the monitor interrupt handling mechanism is not really
> the same as the PVI stuff, although it works somewhat similarly.
In principle, it should be the same --- I think that if you turn on PVI,
it'll work just as well.
> To avoid confusion (especially if we might want to support guests
> that use PVI themselves at a later time),
But this is what the guest flags are for --- I use PVI in the *monitor*
flags. That was the whole point of separating them out !
[snip]
> In any case, copying the monitor's VIF/VIP values into the 'real'
> eflags would appear wrong, as the neither the guest nor the
> processor should be aware of them.
It shouldn't. The *real* processor may be aware of them, so we can use
PVI as an optimization ! and the virtual processor shouldn't be aware
of them anyway, because we catch all accesses to the flags (pushf, popf,
int, iret etc.) and substitute the guest flags in there (see my raise_int/IRET
code for an example).
> [ I'm wondering whether you think that the processor should indeed
> be aware of the VIF/VIP flags, so that we would be able to use the
> real PVI mode ... But I don't believe this can work, because we
> will need to emulate the proper GPF if sti/cli are called in guest
> ring-3 mode and the guest thinks PVI is off. ]
What's the problem ? Just check for guest_cr0&CR0_PVI (yes, we need to
split those out too -- but I needed to start *somewhere* ;))
>- Do we really need a 'mon_eflags' member?
>
> I'm not sure that it might not be simpler to determine the settings
> of those flags where 'real' and guest values differ on-the-fly.
> But this is probably a matter of taste ...
Well, I guess you could substitute this with
bool vip;
bool tf;
/* ... */
... why would you ? My method's cleaner ;)
>- I don't understand this:
>
>+#define FLG_ASYN_MON_MASK (FLG_TF | FLG_VIF | FLG_VIP)
>+#define FLG_ASYN_GST_MASK (FLG_TF)
>
>+ dst |= mon & FLG_ASYN_MON_MASK; \
>+ dst |= gst & FLG_ASYN_GST_MASK; \
>
> Is the intention really to 'or' the TF values of mon_eflags and
> guest_eflags together? Why?
See explanation given above.
-- Ramon
