于 2011/12/16,星期五 15:59, Sasha Levin 写道: > On Fri, 2011-12-16 at 15:40 +0800, Zang Hongyong wrote: >> 于 2011/12/16,星期五 15:05, Sasha Levin 写道: >>> On Fri, 2011-12-16 at 13:32 +0800, zanghongyong@xxxxxxxxxx wrote: >>>> From: Hongyong Zang<zanghongyong@xxxxxxxxxx> >>>> >>>> Vhost-net uses its own vhost_memory, which results from user space (qemu) info, >>>> to translate GPA to HVA. Since kernel's kvm structure already maintains the >>>> address relationship in its member *kvm_memslots*, these patches use kernel's >>>> kvm_memslots directly without the need of initialization and maintenance of >>>> vhost_memory. >>> Conceptually, vhost isn't aware of KVM - it's just a driver which moves >>> data from vq to a tap device and back. You can't simply add KVM specific >>> code into vhost. >>> >>> Whats the performance benefit? >>> >> But vhost-net is only used in virtualization situation. vhost_memory is >> maintained >> by user space qemu. >> In this way, the memory relationship can be accquired from kernel >> without the >> need of maintainence of vhost_memory from qemu. > You can't assume that vhost-* is used only along with qemu/kvm. Just as > virtio has more uses than just virtualization (heres one: > https://lkml.org/lkml/2011/10/25/139 ), there are more uses for vhost as > well. > > There has been a great deal of effort to keep vhost and kvm untangled. > One example is the memory translation it has to do, another one is the > eventfd/irqfd thing it does just so it could signal an IRQ in the guest > instead of accessing the guest directly. > > If you do see a great performance increase when tying vhost and KVM > together, it may be worth it to create some sort of an in-kernel > vhost-kvm bridging thing, but if the performance isn't noticeable we're > better off just leaving it as is and keeping the vhost code general. > Thanks for your explanation. Since memory layout is seldom changed after guest boots, the situation manily occurs during initialization. There's no need for vhost-kvm bridge now. -- 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
