Ramon van Handel wrote:
> 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).
Of course.
> 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 ...?)
As to VIF/VIP, see below.
> 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.
Agreed.
[snip]
> > [ 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.
Of course, you could activate PVI only while executing guest ring-0 code,
or maybe in guest ring-3 code with guest PVI on (but careful: what is VIP
to be, the guest VIP as maintained by the guest OS, the monitor VIP, or a
combination :-/) but this is probably more trouble to get exactly right
than it is worth ...
If you find a simple and efficient solution, that's fine of course;
but I feel that it might be easiest to just consider the VIF/VIP
"guest-only" safe flags, never activate PVI, and emulate the guest PVI
manually (using the context->eflags VIF/VIP) if necessary.
> >- 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 ;)
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. ;)
Bye,
Ulrich
--
Ulrich Weigand,
IMMD 1, Universitaet Erlangen-Nuernberg,
Martensstr. 3, D-91058 Erlangen, Phone: +49 9131 85-27688
