Ramon van Handel <[EMAIL PROTECTED]> wrote:
> Uh, wait. I may be being stupid here, bit why can't software interrupts
> be forwarded to the virtualised code ? I can imagine that we do the
> opposite of what you propose: explicitly forward PIC interrupts,
> but in the handler check whether it was cause by an int instruction
> or by the hardware. That way we know how to handle it.
We don't want to fiddle with the hardware. (We can't acknowledge the
IRQ in the PIC, for example, because the host OS expects to do this.)
How exactly do you want to find out whether the interrupt was in fact
hardware-generated if you can't ask the PIC?
So we'll let the processor do the check whether the interrupt originated
in hardware or software: if the interrupt gate to our handler has a
DPL of 0, software interrupts will trap out to the GPF handler, but
hardware interrupts will come through to the interrupt handler.
We'll need to do this for all interrupts that can possibly be hardware
generated. If we have this information from the host OS (e.g. in the
form of the bitmap I mentioned), we might be able to enter DPL 3 gates
pointing directly to the guest handlers for the *other* interrupts,
those that can never be hardware-generated.
Unfortunately, in the typical case (DOS/Windows under Linux), nearly
all the interesting interrupts (BIOS: 0x1x, DOS: 0x2x) do collide with
hardware vectors, so we'll have to trap out in the large majority of cases
anyway. So, for simplicity, we might as well use that method always ...
Bye,
Ulrich
