>Note that these are somewhat different things:
>
>- A hardware model will allocate a (hardware) IRQ, and will
> *generate* from time to time this interrupt. This will then
> be signaled to the kernel somehow, where guest control is
> transfered to the corresponding handler.
>
>- A debugger will *intercept* a *software* interrupt (int 3),
> so that the monitor doesn't call the handler but returns to
> the user mode app. I don't see how a hardware model should
> need to do this. In fact, except for int3 / int1 I don't
> see why a general facility to redirect software interrupts
> would be needed ...
Indeed, but while you're at it, I see no reason not to do it. It may well
produce some useful effects. And redirecting some processor exceptions to
the user code could be useful also, I reckon. I guess it would also allow
the implementation of zero memory consumption bios-type devices, as long as
you were willing to accept the horrific kludge ;-)
I say that for the extra work it is it may as well be done.
