On 02/27/2010 07:25 AM, Ingo Molnar wrote:
* Zachary Amsden<zamsden@xxxxxxxxxx> wrote:
[...]
Second, it's not over-modularized. The modules are the individual
components of the architecture. How would you propose to put it
differently. They really can't naturally combine. And with the
code quality of qemu in general being problematic by Linux kernel
standards, it's not natural to move the device emulation directly
into the kernel module. So this is why we are where we are today.
I'm not talking about moving it into a kernel _module_ - albeit that
alone is a worthwile thing to do for any performance sensitive hw
component.
I was talking about the option of a clean, stripped down Qemu base
hosted in the kernel proper, in linux/tools/kvm/ or so. If i were
running a virtualization effort it would be the first place i'd
consider to put my tooling into.
The problem is there is no way to clean and strip down the Qemu code.
It's got nicely abstracted bus and device interfaces, for example, but
then these go poking under the covers at things which require
interacting with the display rendering library or remoting interface,
which is not something to reasonably do in the kernel.
So ripping out a clean part interface like PCI bus infrastructure and
using it in the kernel, for example, does nothing except put that
infrastructure in two different places, because everything the kernel
does, userspace will have to do again anyway. So now you have twice as
much code involving the same idea and you have to keep the pieces in
sync and from trampling each other.
The only parts that warrant such complexity and high risk for bugs are
performance critical things like the PIT and APIC.
Zach
--
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
