From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:55067) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cvkxI-0005lF-Kz for qemu-devel@nongnu.org; Wed, 05 Apr 2017 09:26:37 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1cvkxH-0000p3-OT for qemu-devel@nongnu.org; Wed, 05 Apr 2017 09:26:36 -0400 Received: from mail-wr0-x22a.google.com ([2a00:1450:400c:c0c::22a]:34296) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1cvkxH-0000om-I7 for qemu-devel@nongnu.org; Wed, 05 Apr 2017 09:26:35 -0400 Received: by mail-wr0-x22a.google.com with SMTP id t20so14878104wra.1 for ; Wed, 05 Apr 2017 06:26:35 -0700 (PDT) References: <20170330164657.50c75e8c@nial.brq.redhat.com> <87k2764xex.fsf@linaro.org> <20170331102125.52405cd2@nial.brq.redhat.com> <87h9294yba.fsf@linaro.org> <20170405145142.0a417119@nial.brq.redhat.com> From: Alex =?utf-8?Q?Benn=C3=A9e?= In-reply-to: <20170405145142.0a417119@nial.brq.redhat.com> Date: Wed, 05 Apr 2017 14:26:35 +0100 Message-ID: <87wpaz9e9g.fsf@linaro.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Subject: Re: [Qemu-devel] qemu-2.9 crashes in tcg_handle_interrupt() during winx64 boot List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Igor Mammedov Cc: Peter Maydell , Jan Kiszka , qemu-devel@nongnu.org, "Emilio G. Cota" , Paolo Bonzini , Pranith Kumar , KONRAD Frederic , Richard Henderson Igor Mammedov writes: > On Fri, 31 Mar 2017 09:58:49 +0100 > Alex Bennée wrote: > >> Igor Mammedov writes: >> >> > On Thu, 30 Mar 2017 16:05:58 +0100 >> > Alex Bennée wrote: >> > >> >> Igor Mammedov writes: >> >> >> >> > (PS: resend due to wrong qemu-devel mail list address in original >> >> > email) >> >> >> >> Le *sigh* another way of x86 generating IRQs ;-) >> >> >> >> Could you test this please? >> >> >> >> target/i386/misc_helper: wrap BQL around another IRQ generator >> >> >> >> Anything that calls into HW emulation must be protected by the BQL. >> >> >> >> Signed-off-by: Alex Bennée >> > it doesn't help, >> > it asserts in the same place anyway >> >> That's weird. If the lock was already held I could see it failing higher >> up but this seems to imply we are dropping a lock as we descend into >> hardware emulation. > I'm sorry, > when testing it I've misplaced locking into helper_read_crN(), > left write path untouched and went hunting for weird behavior. > > Anyway, > I've tested you patch again and windows guest boots fine with it. No problem - I've done the same before ;-) Can I have a Tested-by? -- Alex Bennée