Ulrich Weigand wrote:
>
> 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.
Yeah that's a good solution :)
But we should avoid it for interrupts that cannot be
hardware-generated.
> 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.
Yes, that is what I want.
> 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 ...
I don't know about windows, but DOS works in real mode :)
We'll probably want to run that in a v86 session, and switch out of
it when it switches to protected mode. That solves that problem
I think... Why virtualise real mode when the processor can do a
good job at that already ?
Ramon
