[win-pv-devel] XENIFACE IOCTL interfaces

[RafaÅ WojdyÅa <omeg@xxxxxxxxxxxxxxxxxxxxxx>]

I was thinking about how to best implement the pended IOCTLs for
resource cleanup and everything I came up with was much more complicated
and error-prone than the process notification solution.

Let's say process X issues a "bind unbound event channel port" IOCTL or
any other IOCTL that needs to persist some state on the driver side. If
such call is pended forever, X needs to pass some kind of value that
identifies the request so a subsequent "get the actual result of that
bind call" IOCTL knows what to return. I suppose those identifiers can
be just call arguments, but it complicates processing when they are not
the same things in different IOCTLs. The driver needs to keep track of
those IDs along with calling processes, and needs a pending IRP queue
that supports IRP cancellation (on caller thread exit). X needs to
allocate OVERLAPPED buffers for every pended IOCTL and keep them in
memory until the request is complete. If X terminates without proper
cleanup, driver's IRP cancel routines are called at DISPATCH_LEVEL in
arbitrary context which makes things like unmapping user memory complicated.

Compared to this, the process notify routine runs at PASSIVE_LEVEL after
all threads have exited and before address space destruction, in the
proper process context. The user mode client doesn't need to keep
anything in memory, all calls are stateless. The driver can just keep a
list of context information for each request, the only identifying
information it needs is the client process. MSDN doesn't seem to imply
that the notification routines are something that may be removed in the
future.

Maybe there is a simpler way to do all this? In any case I'm almost done
implementing pended IOCTLs and they do seem to work properly from
rudimentary testing. I'm just wondering if the increase of code
complexity is worth the effort. At least I've learned some things in the
process :)

Any thoughts?

-- 
RafaÅ WojdyÅa
Qubes Tools for Windows developer
https://www.qubes-os.org/

_______________________________________________
win-pv-devel mailing list
win-pv-devel@xxxxxxxxxxxxxxxxxxxx
http://lists.xenproject.org/cgi-bin/mailman/listinfo/win-pv-devel