Hi Laine,
It appears that patch worked! I grabbed the latest git source for both
libvirt and qemu, applied your patch and reinstalled. After running through
a few more setup stuff, I managed to get my web machine up and running with
tx=bh.
However, I didn't notice any latency improvements compared to timer mode.
My test is pretty basic: I'm connecting to a mysql server, running a simple
query, then disconnecting. On the host guy, this process takes around 5ms.
On the virtual machine, it's around 15ms for both iothread and timer modes.
I'm also comparing this with my other Xen machines in production, which do
the same task in around 12 - 16ms.
I know it sounds like small potatoes, but over the course of running our
somewhat-inefficient webapp, it adds up to around 100ms of overhead for KVM
vs a bare hardware machine.
Any suggestions on that?
Thanks!
--Cal
Not exactly, but close. In the qemu capabilities code, there is a variable
called "is_kvm" that is only set if it finds the string "(qemu-kvm-"
or
"(kvm-" in the help output. It seems to me that this used to be used for a
lot more things, but when I look now I see that it's used for very few
things (maybe a result of the capabilities code refactoring, or maybe my
memory is faulty :-). However, one of the things still in place is that
QEMU_CAPS_VNET_HOST isn't set unless is_kvm is true.
I believe this dependency on is_kvm is there because someone said that the
feature was only in kvm, but retrospectively that doesn't make sense. Can
you try building with the following patch, and see if that works?
diff --git a/src/qemu/qemu_capabilities.c b/src/qemu/qemu_capabilities.c
index ea55df5..71a54a5 100644
--- a/src/qemu/qemu_capabilities.c
+++ b/src/qemu/qemu_capabilities.c
@@ -982,7 +982,7 @@ qemuCapsComputeCmdFlags(const char *help,
if (is_kvm && (version >= 10000 || kvm_version >= 74))
qemuCapsSet(flags, QEMU_CAPS_VNET_HDR);
- if (is_kvm && strstr(help, ",vhost=")) {
+ if (strstr(help, ",vhost=")) {
qemuCapsSet(flags, QEMU_CAPS_VNET_HOST);
}