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

[Jan Kiszka]

Am 07.01.2011 22:19, Gleb Natapov wrote:
> On Fri, Jan 07, 2011 at 08:33:20PM +0100, Jan Kiszka wrote:
>> 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.
>>
> Upstream kvm was not "fork of the fork". It was something much worse
> then that. It was (bad) reimplementation of kvm that was unfortunately
> merged upstream.

Not everything is black or white.

> This slowed proper kvm inclusion into upstream for more
> then 2 years now (and counting). Glauber and you did (and do) a great
> job trying to sort this mess and nobody propose to throw what was done
> so far. qemu-kvm and qemu upstream uses a lot of common code. We can
> either try hard to consolidate even mode code, or at some point just
> merge qemu-kvm and drop upstream functions that are not used by qemu-kvm
> (ifdefed as obsolete in qemu-kvm tree).

Just take a look at the code: this is no longer that easy due to
upstream code being actively even when removing current x86 support. I'm
convinced we can't get around consolidating anymore.

> 
>> 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.
>>
> I do not propose to drop bits from upstream that are used in qemu-kvm
> obviously.
> 
>>>
>>>>>
>>>>> 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.
>>
> No, I didn't. Does io-thread work properly with TCG? IIRC there were
> problems with io thread + TCG.

I'm not using TCG heavily, so I can't say for sure if there are still
issues remaining with the I/O thread. Quite a few were fixed last year,
and I'm currently not aware of open issues.

> 
>>>
>>>> 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.
>>
> This could have been achieved by not introducing upstream kvm in the
> first place :). Many if not most merging problems were result of rival
> kvm implementation in upstream. I thought the goal is to get rid of
> qemu-kvm fork at all by having fully functional kvm in upstream.

I'm quite sure that, by the time kvm upstream was merged, qemu-kvm was
still too far away from a mergable state, not so much its core but its
hooks into and extensions of qemu. So, as far as I understood (Anthony
may correct me), the upstream flavor originally served as an early
teaser for the QEMU folks, opening their mind for the needs and
possibilities of virtualization. However, at latest by the time ppc
adopted this teaser, it became more. And I'm also not that sure we would
be that far now if we tried to dress up qemu-kvm directly for a merge.

What went wrong IMHO was that we were not aggressively enough merging,
specifically once we reached the point where consolidating individual
parts became as easy as it is now. That likely cost more than it saved.

Jan

signature.asc
Description: OpenPGP digital signature