于 2011/12/16,星期五 15:59, Sasha Levin 写道:

On Fri, 2011-12-16 at 15:40 +0800, Zang Hongyong wrote:

quoted

于 2011/12/16,星期五 15:05, Sasha Levin 写道:

quoted

On Fri, 2011-12-16 at 13:32 +0800, zanghongyong@huawei.com wrote:

quoted

From: Hongyong Zang<redacted>

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.