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.
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.
Thanks!
Stefan
Jan
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
