On Wed, Oct 02, 2013 at 08:17:18PM +0000, Hai Nguyen wrote: > Stefan Hajnoczi <stefanha <at> gmail.com> writes: > > > > > On Mon, Sep 30, 2013 at 08:29:30PM -0400, duy hai nguyen wrote: > > > I have this question regarding the way KVM handles I/O requests from a > guest: > > > > > > IO requests from a guest are trapped by KVM. KVM then forwards the > > > requests to QEMU to handle. > > > > > > I am wondering if there is a way to make KVM forward the IO requests > > > to another guest instead of QEMU? I want this second guest to encrypt > > > the data before passing them to QEMU: > > > > > > (I/O from VM1) -> KVM kernel -> VM2 -> QEMU > > > > I don't really understand the trust model you are aiming for. Since > > QEMU has full control over guest RAM and CPU state, QEMU is always > > capable of spying on the guest. > > > > Anyway, QEMU doesn't have a built-in way to bounce the I/O through > > another guest without seeing the data first. > > > > Use a network file system or iSCSI inside the guest. Then VM2 can > > transform the data however you like and transport encryption can be > > used. > > > > Stefan > > -- > > To unsubscribe from this list: send the line "unsubscribe kvm" in > > the body of a message to majordomo <at> vger.kernel.org > > More majordomo info at http://vger.kernel.org/majordomo-info.html > > > > > > Thanks, Stefan! > > In the network file system (NFS) approach you mentioned, I understand that > the I/O requests will go directly from VM1 to VM2 via network before > reaching QEMU for I/O handling. Please correct if I am wrong. The network I/O will go through kvm.ko and either vhost_net.ko or QEMU userspace, but you can encrypt network traffic. Again, I don't really see the point since the hypervisor has access to guest RAM and CPU state - it can always spy on the guest. > > Anyway, QEMU doesn't have a built-in way to bounce the I/O through > > another guest without seeing the data first. > > I want to have I/O requests from VM1 go to VM2 first. In the current design > of kvm kernel module, kvm forwards I/O requests to QEMU by setting some > fields in the 'vcpu' structure and each QEMU thread keeps checking the > content of their corresponding vcpu. Is this the part I can make changes to > have my I/O path? Yes. You'll need to share the guest RAM so the other process can read/write guest I/O buffers. 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
