On 2011-01-24 19:27, Stefan Berger wrote:
> On 01/18/2011 03:53 AM, Jan Kiszka wrote:
>> On 2011-01-18 04:03, Stefan Berger wrote:
>>> On 01/16/2011 09:43 AM, Avi Kivity wrote:
>>>> On 01/14/2011 09:27 PM, Stefan Berger wrote:
>>>>>> Can you sprinkle some printfs() arount kvm_run (in qemu-kvm.c) to
>>>>>> verify this?
>>>>>>
>>>>> Here's what I did:
>>>>>
>>>>>
>>>>> interrupt exit requested
>>>> It appears from this you're using qemu.git.  Please try qemu-kvm.git,
>>>> where the code appears to be correct.
>>>>
>>> Cc'ing qemu-devel now. For reference, here the initial problem
>>> description:
>>>
>>> http://www.spinics.net/lists/kvm/msg48274.html
>>>
>>> I didn't know there was another tree...
>>>
>>> I have seen now a couple of suspends-while-reading with patches applied
>>> to the qemu-kvm.git tree and indeed, when run with the same host kernel
>>> and VM I do not see the debugging dumps due to double-reads that I would
>>> have anticipated seeing by now. Now what? Can this be easily fixed in
>>> the other Qemu tree as well?
>> Please give this a try:
>>
>> git://git.kiszka.org/qemu-kvm.git queues/kvm-upstream
>>
>> I bet (&  hope) "kvm: Unconditionally reenter kernel after IO exits"
>> fixes the issue for you. If other problems pop up with that tree, also
>> try resetting to that particular commit.
>>
>> I'm currently trying to shake all those hidden or forgotten bug fixes
>> out of qemu-kvm and port them upstream. Most of those subtle differences
>> should hopefully soon be history.
>>
> I did the same test as I did with Avi's tree and haven't seen the
> consequences of possible double-reads. So, I would say that you should
> upstream those patches...
> 
> I searched for the text you mention above using 'gitk' but couldn't find
> a patch with that headline in your tree. There were others that seem to
> be related:
> 
> Gleb Natapov: "do not enter vcpu again if it was stopped during IO"

Err, I don't think you checked out queues/kvm-upstream. I bet you just
ran my master branch which is a version of qemu-kvm's master. Am I right? :)

>>> One thing I'd like to mention is that I have seen what I think are
>>> interrupt stalls when running my tests inside the qemu-kvm.git tree
>>> version and not suspending at all. A some point the interrupt counter in
>>> the guest kernel does not increase anymore even though I see the device
>>> model raising the IRQ and lowering it. The same tests run literally
>>> forever in the qemu.git tree version of Qemu.
>> What about qemu-kmv and -no-kvm-irqchip?
> That seems to be necessary for both trees, yours and the one Avi pointed
> me to. If applied, then I did not see the interrupt problem.

And the fact that you were able to call qemu from my tree with
-no-kvm-irqchip just underlines my assumption: that switch is refused by
upstream. Please retry with the latest kvm-upstream queue.

Besides that, this other bug you may see in the in-kernel IRQ path - how
can we reproduce it?

Jan