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
