Oops, previous send was an accident - I was trying to send a different
e-mail. Sorry about the empty post.
Now for the real one(:-)
James wrote:
> I should think an interface like this would be happy:
> Guest Driver Initiated
> ----------------------
> Guest creates a buffer, and fills it in.
>
>
> Guest sets ES:DI with the address of the buffer, AX with the length of
> the buffer, BH with the subsystem ID (IE 'n' for network) and BL with a
code
> specific for the subsystem.
>
>
> Guest executes some specific bad opcode, which causes a fault.
>
>
> Monitor catches the fault, checks that it's of the correct bad opcode, and
> passes it to the host.
>
Yeh, for the longest time I thought we'd have to do something like that,
then I bumped into a "clue stick". The Plex86 monitor is already trapping IO
instructions, so why not just define an I/O address that means "Address of
driver X's buffer" then write the address to that location. Hmm, this would
take a 32-bit I/O. Does x86 support that? Anyway, somehow we could use the
I/O trap - maybe assign a 64K output region and the driver sends an offset?
Simpler, conceptually, and not vulnerable to new opcodes.
>
> Host does processing, and sets BX to 0 if there is no error, or gives an
> error code in BX otherwise. Some might want to return more then 64 bits of
> state, in that case it should overwrite the buffer given. Only the BX
> register should be changed, though, to insure a consistent interface.
>
Or a status location is shared and filled after the I/O request has been
processed?
>
>
> Host Initated
> -------------
> Host sets registers as described above, and does an INT3 in the guest.
(I'm
> assuming that hw int 3 will never happen other then this, since it's used
> for emulation. Am I correct in this?) We map the host's buffer in
> somewhere. I'd say that above any point that has yet been accessed. On
> IRET, we unmap it, so as not to step on any toes. If the interupt handler
> isn't finished with the data, it should copy it.
>
Well, I don't know about other OSes, but this doesn't fit well with the
windows NDIS architecture. Windows has an "ISR" (actually a procedure call
from the actual ISR, which is pure windows code), which is supposed to do
almost nothing, and which triggers a Delayed Procedure Call, which is called
from a high priority thread and is supposed to do the bulk of the work
(including data transfers). How about the host emulating a hardware
interrupt, then the Guest driver signals the completion of buffer processing
with another IO (at which point the buffer is guaranteed releasable by the
Guest driver)?
P.s. Thanks for your interpretation of my rambling earlier. It was much
clearer and either exactly what I meant or better than what I was trying to
say.
