Stefan Hajnoczi <stefanha <at> gmail.com> writes: > > 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 Thank you very much! We are working with a threat model where we do trust the KVM hypervisor. However, we would like to route the I/O from our VM1 into another VM2, where it can service the I/O appropriately (e.g., do intrusion detection, etc). For performance reasons, we'd like this I/O path to go directly from VM1 to VM2, rather than VM1 to VM2 via QEMU. Is this doable? Best, Hai -- 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
