[Qemu-devel] Re: qemu-kvm vs. qemu: Terminate cpu loop on reset?

[Jan Kiszka <jan.kiszka@web.de>]

[-- Attachment #1: Type: text/plain, Size: 2416 bytes --]

Am 07.01.2011 20:10, Gleb Natapov wrote:
>>>> We are on a good track now. I predict that we will be left with only one
>>>> or two major additional features in qemu-kvm in a few months from now,
>>>> no more duplications with subtle differences, and production-grade kvm
>>>> upstream stability.
>>>>
>>> You are optimistic. My prediction is that it will take at least one major RHEL
>>> release until such merged code base will become production-grade. That
>>> is when most bugs that were introduced by eliminating subtle differences
>>> between working and non-working version will be found :)
>>
>> The more upstream code qemu-kvm stresses, the faster this convergence
>> will become. And there is really not that much left. E.g, I've a
>> qemu-kvm-x86.c here that is <400 LOC.
>>
> That's what I don't get. Why working qemu-kvm should stress non working
> upstream code? Just remove upstream code and replace it with qemu-kvm
> version.

We are 3/4 (if not more) done with refactoring qemu-kvm into a clean
state, removing lots of cruft from libkvm days and early kvm modules. We
achieved this by creating a "fork of the fork": upstream kvm. We may
argue a lot about pros and cons of this approach, but it is a fact now.
And a lot of effort would be wasted as well by throwing this away.

Moreover, taking off the x86 glasses: ppc and s390 rely on upstream kvm.
So it is impossible to drop those bits without breaking all non-x86 kvm
archs.

> 
>>>
>>> BTW Do you have a plan how to move upstream to thread per vcpu?
>>
>> Upstream has this already, but it's - once again - a different
>> implementation. Understanding those differences is one of the next steps.
>>
> I see only two threads on upstream no matter how much vcpus I configure.

/me sees a lot of them. Did you enable io-thread support? Otherwise kvm
is run just like tcg in single-thread mode.

> 
>> In fact, as posted recently, unifying the execution model
>> implementations is the only big problem I see. In-kernel irqchips and
>> device assignment are things that can live in qemu-kvm without much
>> conflicts until they are finally mergable.
>>
> Upstream kvm is kinda useless without in-kernel irqchips.

Not if its code serves the rest of qemu-kvm without further patches (and
merge conflicts). And we only need to sort out the execution loop and
threading stuff to get there.

Jan


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 259 bytes --]