Ulrich Weigand wrote:
> > 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.)
>
> This is where I'm sceptical; of course the monitor needs flags to
> remember various settings, but I'm not sure that those really correspond
> 1-1 to the processor flags. (Of course the processor flags are *determined*
> by the current monitor status, but that's not the same ...)
>
> Take the TF for example: we need to remember not only that we have to set
> TF, but also *why* we have done so (for ICE debugging, or for emulating
> STI, or ...?)
The user-level monitor cannot directly change the monitor flag.
So we need to implement a 'single step' IOCTL. This means that
the monitor should in principle always 'know' why TF is set;
okay, that is not stored in the monitor flags but elsewhere,
but it seems to me it's a lot cleaner to separate out the actual
monitor flags settings (used for constructing the user flags)
and the reasons for setting them (used by the exception handler
to determine how to handle the exception) --- they're used by
different parts of the monitor.
In order to solve they 'why' problem, we need to introduce a new
set of flags that determine what the monitor is doing (a state-
machine like construction). It may seem that if we have those
flags, we don't *need* the monitor flags anymore, but I don't
really agree with that. If you have only your monitor-state
flags, then constructing the user flags becomes a very complicated
procedure, which involves checking every flag in the state flags
separately and determining on the basis of that what to do in
the user flags. You're much better off "mirroring" this information
in a monitor flags field, so you can access it later much more
effectively.
> > > [ 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* ;))
>
> You can only check if the monitor gets invoked in the first place.
> If the guest PVI is off, but the monitor activates PVI as an optimization,
> then every guest sti instruction will just set the VIF flag, and not trap to
> the monitor (unless VIP happens to be set). Thus, the monitor has no chance
> to call the guest GPF handler, which it actually should.
Okay, you've convinced me. I'll update my patch accordingly..
Though, I probably won't have time today --- I'll try to get
a new patch ready later this week.
> > Well, I guess you could substitute this with
> >
> > bool vip;
> > bool tf;
> > /* ... */
> >
> > ... why would you ? My method's cleaner ;)
>
> Well, if it turns out that the VIP can't actually be copied to the real
> flags (although we still need to store it!), and that we don't just need a TF,
> but a TF_because_ICE and a TF_because_STI etc., then it might be cleaner
> not to pretend that the monitor settings correspond 1-1 to processor flags. ;)
But not more efficient... see above.
-- Ramon
