On Tue, Dec 19, 2000 at 09:48:12AM -0800, Colin Davidson wrote:
> James wrote:
> > Guest executes some specific bad opcode, which causes a fault.
> why not just define an I/O address that means "Address of
> driver X's buffer" then write the address to that location.
Sounds good to me. Thanks for hitting me over the head with the clue stick.
> Hmm, this would take a 32-bit I/O. Does x86 support that?
Yep, inl/outl. Sounds like a good idea to me.
> Or a status location is shared and filled after the I/O request has been
> processed?
That isn't reentrant. It shouldn't come up much, but doing it right the
first time is generaly a Good Thing, so long as it doesn't complicate things
too much.
> 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)?
Hm, that was exactly what I was worrying about. Doing another IO sounds
good to me -- I think we should assign a generic BH:BL for "I'm done with
the buffer, unmap it". ('p':'u' sounds good to me -- 'p' for plex86, of
course. 'g' for general would better be 'g' for graphics.)
-=- James Mastros
--
midendian: She never sleeps.
mousetrout: But I do. I just regret it after I wake up.
AIM: theorbtwo homepage: http://www.rtweb.net/theorb/
ICBM: 40:04:15.100 N, 76:18:53.165 W
