Re: [Qemu-devel] Re: Errors on MMIO read access on VM suspend / resume operations

[Jan Kiszka]

On 2011-01-25 04:13, Stefan Berger wrote:
> On 01/24/2011 05:34 PM, Jan Kiszka wrote:
>> 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? :)
>>
> 
> You're right. :-) my lack of git knowledge -  checked out the branch now.
> 
> I redid the testing and it passed. No double-reads and lost bytes from
> what I could see.

Great, thanks.

> 
>>>>> 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?
> Unfortunately I don't know. Some things have to come together for the
> code I am working on to become available and useful for everyone. It's
> going to be a while.

Do you see a chance to look closer at the issue yourself? E.g.
instrument the kernel's irqchip models and dump their states once your
guest is stuck?

Jan

signature.asc
Description: OpenPGP digital signature