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
Attachment:
signature.asc
Description: OpenPGP digital signature
