On Fri, 31 Mar 2017 09:58:49 +0100
Alex Bennée <alex.ben...@linaro.org> wrote:
> Igor Mammedov <imamm...@redhat.com> writes:
>
> > On Thu, 30 Mar 2017 16:05:58 +0100
> > Alex Bennée <alex.ben...@linaro.org> wrote:
> >
> >> Igor Mammedov <imamm...@redhat.com> 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 <alex.ben...@linaro.org>
> > 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
