From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jan Kiszka Subject: Re: qemu-kvm-1.1.0 crashing with kernel 3.5.0-rc6 Date: Thu, 26 Jul 2012 13:04:59 +0200 Message-ID: <5011245B.9010202@siemens.com> References: <4FFAB92C.4030001@googlemail.com> <4FFD26B6.8000802@googlemail.com> <20120711071200.GG23898@redhat.com> <4FFD28B9.9040604@googlemail.com> <20120711072255.GH23898@redhat.com> <50031F85.6020908@googlemail.com> <5007FA1C.5080606@googlemail.com> <5007FAD6.2010407@redhat.com> <500850AD.8080504@googlemail.com> <50111369.6020209@googlemail.com> <50111566.5070202@redhat.com> <50111BFB.8080606@siemens.com> <50111FE5.8090801@redhat.com> <501120CA.10704@siemens.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit Cc: Chris Clayton , Gleb Natapov , "kvm@vger.kernel.org" To: Avi Kivity Return-path: Received: from david.siemens.de ([192.35.17.14]:15801 "EHLO david.siemens.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751720Ab2GZLFF (ORCPT ); Thu, 26 Jul 2012 07:05:05 -0400 In-Reply-To: <501120CA.10704@siemens.com> Sender: kvm-owner@vger.kernel.org List-ID: On 2012-07-26 12:49, Jan Kiszka wrote: > On 2012-07-26 12:45, Avi Kivity wrote: >> On 07/26/2012 01:29 PM, Jan Kiszka wrote: >> >>>> It looks like general memory corruption. Is this repeatable? What's >>>> the guest uptime when it happens (i.e. is it immediate?) >>>> >>>> Jan, why are we calling cpu_set_apic_tpr() with kvm_irqchip_in_kernel? >>> >>> To sync the userspace state with what the kernel maintains. Will end up >>> in kvm_apic_set_tpr which does precisely this. We always did, just the >>> QOM modeling is new. >> >> We should move it to the general register synchronization code, there is >> no reason to do this every exit (though the cost is likely minimal). > > The cost is, well, was close to nothing. But I'm not sure about that QOM > type casting magic (and also it's locking requirements, long-term). > However, if that is a problem, it's likely a much bigger one anyway. But, independent of this, we can likely move the whole kvm_arch_post_run out of the exit path for kvm_irqchip_in_kernel() == true. The price is that we create more deviation between both, but that should be controllable. I will play with a patch. Jan -- Siemens AG, Corporate Technology, CT RTC ITP SDP-DE Corporate Competence Center Embedded Linux