Anthony Liguori wrote:
Avi Kivity wrote:
The refactoring, absolutely. But if I have kernel support for zero
copy tomorrow, do I wait until qemu completes refactoring the VLAN
API, or do I hack something in so I can test it and get the benefit
to users?
Why can't we do this in upstream QEMU though? Part of the point I'm
trying to make here is that what QEMU is can be flexible.
If we do it the right way, it takes time, and we serialize development
(for example, we don't find and fix bugs in the kernel).
We don't want to do it the wrong way.
We can find ways to include functionality that might not be ready for
prime time by making it conditionally compiled, only available when
using KVM, etc. It's all open for discussion. So I'll be quite blunt
about it, what needs to change about what QEMU takes and doesn't take
in order to get rid of kvm-userspace?
#ifdefs in master, an experimental branch, and kvm-userspace (soon,
qemu-kvm) are all equivalent.
There's even an option to diff(1) to generate #ifdefs instead of the
traditional diff markers.
Experimentation is a good thing. It's also important to do things the
right way as early as possible though because the longer users depend
on something, the harder it is to change later. I think it's easier
to strike that balance in upstream QEMU than trying to port things
from kvm-userspace over to QEMU after the fact.
Well, let's take it on a case by case basis. I certainly prefer to see
everything go to qemu.git. If we find a case where it isn't workable,
qemu-kvm.git can be a temporary home.
We can have KVM specific features in QEMU when that makes sense. In
the case of MCE, it doesn't make any sense because it's relatively
simple and the implementation can be common given the right interfaces.
The kvm kernel module doesn't have common implementation for qemu/tcg
and qemu/kvm as one of its goals. It doesn't know anything about qemu.
It wants to export an interface that makes sense (is as close to the cpu
model as possible).
The few places that we inadvertently let qemuisms slip through turned
out to be mistakes.
I agree that MCE is simple so it's easy to implement in both. But the
other features may be different.
--
error compiling committee.c: too many arguments to function
--
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