Re: [Qemu-devel] qemu-2.9 crashes in tcg_handle_interrupt() during winx64 boot

[Igor Mammedov]

On Fri, 31 Mar 2017 09:58:49 +0100
Alex Bennée <address@hidden> wrote:

> Igor Mammedov <address@hidden> writes:
> 
> > On Thu, 30 Mar 2017 16:05:58 +0100
> > Alex Bennée <address@hidden> wrote:
> >  
> >> Igor Mammedov <address@hidden> 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 <address@hidden>  
> > 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.

> How often does this leg of the helper get called?
> 
> >  
> >>
> >> 1 file changed, 2 insertions(+)
> >> target/i386/misc_helper.c | 2 ++
> >>
> >> modified   target/i386/misc_helper.c
> >> @@ -156,7 +156,9 @@ void helper_write_crN(CPUX86State *env, int reg, 
> >> target_ulong t0)
> >>          break;
> >>      case 8:
> >>          if (!(env->hflags2 & HF2_VINTR_MASK)) {
> >> +            qemu_mutex_lock_iothread();
> >>              cpu_set_apic_tpr(x86_env_get_cpu(env)->apic_state, t0);
> >> +            qemu_mutex_unlock_iothread();
> >>          }
> >>          env->v_tpr = t0 & 0x0f;
> >>          break;
> >> --
> >> Alex Bennée
> >>  
> 
> 
> --
> Alex Bennée