[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PATCH v3 4/4] tcg: rework tb_invalidated_flag
From: |
Sergey Fedorov |
Subject: |
Re: [Qemu-devel] [PATCH v3 4/4] tcg: rework tb_invalidated_flag |
Date: |
Thu, 21 Apr 2016 19:16:33 +0300 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 |
On 21/04/16 18:55, Alex Bennée wrote:
> Sergey Fedorov <address@hidden> writes:
>
>> On 18/04/16 20:51, Sergey Fedorov wrote:
>>> On 18/04/16 20:17, Alex Bennée wrote:
>>>> Sergey Fedorov <address@hidden> writes:
>>>>> On 18/04/16 17:09, Alex Bennée wrote:
>>>>>> Sergey Fedorov <address@hidden> writes:
>>>>>>> diff --git a/cpu-exec.c b/cpu-exec.c
>>>>> (snip)
>>>>>>> @@ -507,14 +510,12 @@ int cpu_exec(CPUState *cpu)
>>>>>>> }
>>>>>>> tb_lock();
>>>>>>> tb = tb_find_fast(cpu);
>>>>>>> - /* Note: we do it here to avoid a gcc bug on Mac OS X
>>>>>>> when
>>>>>>> - doing it in tb_find_slow */
>>>>>> Is this still true? Would it make more sense to push the patching down
>>>>>> to the gen_code?
>>>>> This comment comes up to the commit:
>>>>>
>>>>> commit 1538800276aa7228d74f9d00bf275f54dc9e9b43
>>>>> Author: bellard <address@hidden>
>>>>> Date: Mon Dec 19 01:42:32 2005 +0000
>>>>>
>>>>> workaround for gcc bug on PowerPC
>>>>>
>>>>>
>>>>> It was added more than ten years ago. Anyway, now this code is here not
>>>>> because of the bug: we need to reset 'next_tb' which is a local variable
>>>>> in cpu_exec(). Personally, I don't think it would be neater to hide it
>>>>> into gen_code(). Do you have some thoughts on how we could benefit from
>>>>> doing so? BTW, I had a feeling that it may be useful to reorganize
>>>>> cpu_exec() a bit, although I don't have a solid idea of how to do this
>>>>> so far.
>>>> I'm mainly eyeing the tb_lock/unlock which would be nice to push further
>>>> down the call chain if we can, especially if the need to lock
>>>> tb_find_fast can be removed later on.
>>> Yes, it would be nice to possibly have all tb_lock/unlock() calls (or at
>>> least their pairs) in the same block. There is a lot to be thought over :)
>> It's not so simple because tb_find_fast() is also called in replay mode
>> to find a TB for cpu_exec_nocache()... I'm not sure it's worth touching
>> it now.
> If the locking is pushed into tb_find_fast or further down is this an
> issue?
We would have to pass 'next_tb' (or 'last_tb' and 'tb_exit' after
cleaning it up) if we move TB chaining code to tb_find_fast(). But
tb_find_fast() is also called in replay mode to find a TB for
cpu_exec_nocache() where we don't bother with TB chaining... Do you
think it would be fine to make those changes?
Kind regards,
Sergey
- [Qemu-devel] [PATCH v3 2/4] tcg: reorganize tb_find_physical loop, (continued)
- [Qemu-devel] [PATCH v3 2/4] tcg: reorganize tb_find_physical loop, Sergey Fedorov, 2016/04/14
- [Qemu-devel] [PATCH v3 3/4] cpu-exec: elide more icount code if CONFIG_USER_ONLY, Sergey Fedorov, 2016/04/14
- [Qemu-devel] [PATCH v3 4/4] tcg: rework tb_invalidated_flag, Sergey Fedorov, 2016/04/14
- Re: [Qemu-devel] [PATCH v3 4/4] tcg: rework tb_invalidated_flag, Alex Bennée, 2016/04/18
- Re: [Qemu-devel] [PATCH v3 4/4] tcg: rework tb_invalidated_flag, Sergey Fedorov, 2016/04/18
- Re: [Qemu-devel] [PATCH v3 4/4] tcg: rework tb_invalidated_flag, Peter Maydell, 2016/04/18
- Re: [Qemu-devel] [PATCH v3 4/4] tcg: rework tb_invalidated_flag, Alex Bennée, 2016/04/18
- Re: [Qemu-devel] [PATCH v3 4/4] tcg: rework tb_invalidated_flag, Sergey Fedorov, 2016/04/18
- Re: [Qemu-devel] [PATCH v3 4/4] tcg: rework tb_invalidated_flag, Sergey Fedorov, 2016/04/21
- Re: [Qemu-devel] [PATCH v3 4/4] tcg: rework tb_invalidated_flag, Alex Bennée, 2016/04/21
- Re: [Qemu-devel] [PATCH v3 4/4] tcg: rework tb_invalidated_flag,
Sergey Fedorov <=
- Re: [Qemu-devel] [PATCH v3 4/4] tcg: rework tb_invalidated_flag, Sergey Fedorov, 2016/04/21
- Re: [Qemu-devel] [PATCH v3 4/4] tcg: rework tb_invalidated_flag, Alex Bennée, 2016/04/21
- Re: [Qemu-devel] [PATCH v3 4/4] tcg: rework tb_invalidated_flag, Sergey Fedorov, 2016/04/22