Re: Perform mmap and poll on PUD character devices

[Thor Lancelot Simon <tls%panix.com@localhost>]

On Sun, Sep 11, 2011 at 08:58:53PM +0200, Roger Pau Monn? wrote:
> > I can't see how a userland implementation can have better performances
> > than an all in-kernel implementation. There are more context switches,
> > which are notr so cheap with Xen.
> 
> >From what I understand using blktap with Xen provides better
> performance because it is designed specifically for this task (attach
> disks to virtual machines), and uses asynchronous I/O, not because
> it's implemented in userspace (if the whole thing was implemented
> inside the kernel it will of course be faster, but it would also be
> more dangerous regarding the security of the Dom0).

I do not understand this.  Both the Linux "loop" driver and our "vnd"
driver provide virtual disks suitable for attachment to virtual machines,
and, since they are within the kernel and do not spin on CPU, their I/O
is inherently "asynchronous".

Similarly, I am not sure I believe the security justification, mostly
because I don't really see why I should believe that the very complex
memory management code involved in providing the split kernel/user
memory-mapped device driver interface this seems to require is less
likely to have security-critical bugs than a comparatively simple
addition of in-kernel support for a few different virtual disk layouts
than the ones we already have code for.

Basically, the reasons to put this in userspace really look like
well-intentioned handwaving to me.

Finally, isn't it possible to simply isolate the server side of a
Xen block driver in its own domain?  At that point the security of
the dom0 really depends not at all on whether the virtual block driver
lives entirely in kernel or is split between the kernel and userspace.

Thor