[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] Weird behavior while using the instruction counter
From: |
Luis Pureza |
Subject: |
Re: [Qemu-devel] Weird behavior while using the instruction counter |
Date: |
Thu, 24 Jul 2008 18:58:58 +0100 |
On Thu, Jul 24, 2008 at 5:02 PM, Paul Brook <address@hidden> wrote:
>> > I don't think this is correct. If we have chained TBs then the jump cache
>> > entry may have been overwritten by a different TB.
>> > It's also inefficient. If we didn't get here via cpu_exec_nocache then we
>> > can invalidate a TB unnecessarily.
>> >
>> > Anywhere that uses tb_find_pc/cpu_restore_state is probably broken and
>> > will need auditing for the problems I mentioned above.
>>
>> Ok. In the meanwhile, I'll stick with
>>
>> tb2 = env->tb_jmp_cache[tb_jmp_cache_hash_func(tb->pc)];
>> if (tb2 && tb2 != tb && tb2->pc == tb->pc && tb2->cs_base ==
>> tb->cs_base && tb2->flags == tb->flags) {
>> tb_phys_invalidate(tb2, -1);
>> }
>>
>> Unless, of course, you tell me there's something horribly wrong with this
>> :-) Thank you,
>
> If by "horribly wrong" you mean won't work reliably and is just making the bug
> a bit harder to find, then it's no better then the previous change.
> It just avoids a few of the unnecessary (but harmless) invalidations.
I see.
One last try then... Would the invalidation of the original TB by
cpu_exec_nocache() solve the problem (despite being terribly
inefficient)?
Thanks,
Luis Pureza