Generic int 13h driver

[Die Gestalt]

On 5/23/07, Die Gestalt <die.gestalt at gmail.com> wrote:
>
>
>  So I will have to write an interrupt handler that catches the IRQ14, has
> got the address of the IRQ14 handler of the BIOS, run this handler in the
> VM86, and pray The Great Sysop? :p
>

Indeed this is what I have to do. I've dwelled inside the heart of the
kernel to see how I could set up a hardcore general IRQ 14 handler. This
works.

This handler should call do a simple vm86_intcall(0x76....) (int 76h is
the BIOS handler for the IRQ 14), but the problem is that this results in a
deadlock for the very simple fact that the BVM86 is still running waiting
for the completion....

I thought about creating a second virtual machine monitor (well simply
setting up some pages in locland modifying vm86_initialize and add some
vm86_intcall2 functions), but my question is... If I do a vm86_intcall2 from
my IRQ14 handler, will the first vm86_datacall (still running) be aware of
it? This is Plan A.

Plan B would be to be able to stop execution of the first vm86_datacall,
save the current context, and replace the code to run before resuming to the
IRQ14, when its finished, the previous context is restored. For now I have
absolutely no idea about how to do it. :)

Well the save/restore context is not very difficult, I could write the
following code:

save context
save ip
push marker on stack
int 76h -> iret

I will end up in vm86_trap

in vm86_trap if I see my marker on the stack I do a

pop marker
restore context
get ip back
resume execution at ip

But how to stop the vm86_datacall and patch it in. It would be much better
if Plan A works. :p

Any input greatly welcomed.