Re: [win-pv-devel] XENIFACE IOCTL interfaces

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

On 2015-09-23 02:59, RafaÅ WojdyÅa wrote:
> 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 :)
> 
Just as I wrote this I realized I can free event channels and such when
the file object is closed so their IOCTLs don't need to be pended. This
does simplify things significantly although I wonder if it doesn't leave
any holes if the driver handle is duplicated by another 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