2015-01-16 19:00 GMT+08:00 Stefan Hajnoczi <stefanha@xxxxxxxxx>: > On Fri, Jan 16, 2015 at 12:14:17PM +0800, Yidao Liu wrote: >> Hi, I want to use a dedicated guest VM to handle I/O request just as >> I/O service domain used in xen. >> >> Specifically, using network I/O as an example, I should directly >> assign the NIC to one guest VM (using pci-assign option), after that >> all other guest VMs should perform network I/O through that VM rather >> than the host OS. >> >> Is there currently any viable approach to do this? >> >> If not, I want to implement one. Currently I'm thinking of combining >> nahanni shared memory and vhost architecture to implement it, is there >> any other suggestions? > > There are security features like SELinux, seccomp, and file descriptor > passing that allow the QEMU userspace process to run unprivileged. > Why does it matter if the I/O is happening in an isolated userspace > process or another VM? > Although we use unprivileged Qemu to emulate the I/O operation, current I/O mechanism still need to use Host to do the last part of I/O, so if there's any bug in this phase, the whole system may crash due to the Host OS down, is it? So if using I/O service domain, there's no such problem, only service domain will crash rather than the whole system. > You can of course have appliance VMs that do network I/O on behalf of > other guests. Assign the physical NIC to the appliance VM and then use > a private bridge on the host so guests can only communicate through the > appliance VM. > I'm curious why use a private bridge on the host, but not in the appliance VM? since the physical NIC is already assigned to the VM. > My Xen knowledge is very limited but I think part of why this > architecture is attractive there is because there is already a mechanism > for granting pages - i.e. secure inter-domain DMA. > > In QEMU the architecture is different, so I wonder what you're trying to > achieve. It will be slower and more convoluted than how it works today. > > What are you trying to achieve? > Thanks for your reply, actually it is a research trial, we want to use a non-root guest VM to provide the I/O service, rather than the Qemu+host-os, to provide better fault isolation. > Stefan -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
