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

[Paul Durrant <Paul.Durrant@xxxxxxxxxx>]

> -----Original Message-----
> From: win-pv-devel-bounces@xxxxxxxxxxxxxxxxxxxx [mailto:win-pv-devel-
> bounces@xxxxxxxxxxxxxxxxxxxx] On Behalf Of Rafal Wojdyla
> Sent: 23 September 2015 02:18
> To: win-pv-devel@xxxxxxxxxxxxxxxxxxxx
> Subject: Re: [win-pv-devel] XENIFACE IOCTL interfaces
> 
> 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...
>

I wouldn't worry about that at this stage. Do you envisage the ioctl interface 
being available to non-privileged users? If not then cleanup on file object 
destruction is fine (with ioctls to do explicit evtchn close, grant unmap, 
etc.). If you are expecting this to be available to non-privileged users then I 
guess we need to have per-user quotas on resources... event channels we have 
loads of in theory (if fifo is being used) and we really can't expose grant 
mapping directly.

  Paul

 
> > 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
_______________________________________________
win-pv-devel mailing list
win-pv-devel@xxxxxxxxxxxxxxxxxxxx
http://lists.xenproject.org/cgi-bin/mailman/listinfo/win-pv-devel