Jens Nerche <[EMAIL PROTECTED]> wrote:

> I played around with interrupt handling. Inserting cli or
> sti in guest/virtcode/virtcode should effect abort due to
> exception 13 (GP), but does not. 

Oops, this is my fault ...  Try changing  lines 373/4 of monitor.c from

    guest_context->eflags &= ~0x00004100;  /* clear NT/TF */
    guest_context->eflags |=  0x00003200;  /* set IF, IOPL 3 */

to

    guest_context->eflags &= ~0x00007100;  /* clear NT/TF, set IOPL 0 */
    guest_context->eflags |=  0x00000200;  /* set IF */

Doh!  (You probably locked up your machine nicely :-/)


> Inserting int3 should cause exception3, but does exception 13. 

This is because the INT 3 gate (like all our other interrupt gates) 
has privilege level 0, which means that it only be reached from ring-0.
Trying to call this from ring-3 generates a GPF instead.

We do this so that we can distinguish between interrupts generated 
from hardware, and software int xx calls (we don't want to have
a int xx generated by the client forwarded to the host as 'hardware'
interrupt!).

Of course in the case of int3 it might be debatable whether it would
not be easier to set the gate privilege level to 3, so that our int3
handler gets called directly ...

Bye,
Ulrich

Reply via email to