[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Qemu-devel] Re: qemu-kvm vs. qemu: Terminate cpu loop on reset?
From: |
Jan Kiszka |
Subject: |
[Qemu-devel] Re: qemu-kvm vs. qemu: Terminate cpu loop on reset? |
Date: |
Fri, 07 Jan 2011 20:33:20 +0100 |
User-agent: |
Mozilla/5.0 (X11; U; Linux i686 (x86_64); de; rv:1.8.1.12) Gecko/20080226 SUSE/2.0.0.12-1.1 Thunderbird/2.0.0.12 Mnenhy/0.7.5.666 |
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
signature.asc
Description: OpenPGP digital signature
- [Qemu-devel] qemu-kvm vs. qemu: Terminate cpu loop on reset?, Jan Kiszka, 2011/01/07
- [Qemu-devel] Re: qemu-kvm vs. qemu: Terminate cpu loop on reset?, Gleb Natapov, 2011/01/07
- [Qemu-devel] Re: qemu-kvm vs. qemu: Terminate cpu loop on reset?, Jan Kiszka, 2011/01/07
- [Qemu-devel] Re: qemu-kvm vs. qemu: Terminate cpu loop on reset?, Gleb Natapov, 2011/01/07
- [Qemu-devel] Re: qemu-kvm vs. qemu: Terminate cpu loop on reset?, Jan Kiszka, 2011/01/07
- [Qemu-devel] Re: qemu-kvm vs. qemu: Terminate cpu loop on reset?, Gleb Natapov, 2011/01/07
- [Qemu-devel] Re: qemu-kvm vs. qemu: Terminate cpu loop on reset?, Jan Kiszka, 2011/01/07
- [Qemu-devel] Re: qemu-kvm vs. qemu: Terminate cpu loop on reset?, Jan Kiszka, 2011/01/07
- [Qemu-devel] Re: qemu-kvm vs. qemu: Terminate cpu loop on reset?, Gleb Natapov, 2011/01/07
- [Qemu-devel] Re: qemu-kvm vs. qemu: Terminate cpu loop on reset?,
Jan Kiszka <=
- [Qemu-devel] Re: qemu-kvm vs. qemu: Terminate cpu loop on reset?, Gleb Natapov, 2011/01/07
- [Qemu-devel] Re: qemu-kvm vs. qemu: Terminate cpu loop on reset?, Jan Kiszka, 2011/01/08