qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH] atomics: add volatile_read/volatile_set


From: Paolo Bonzini
Subject: Re: [Qemu-devel] [PATCH] atomics: add volatile_read/volatile_set
Date: Mon, 18 Jul 2016 19:58:28 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.1.1


On 18/07/2016 19:31, Sergey Fedorov wrote:
> On 18/07/16 20:28, Paolo Bonzini wrote:
>>
>> On 18/07/2016 19:25, Sergey Fedorov wrote:
>>>>> @@ -753,14 +753,14 @@ static inline void 
>>>>> cpu_get_invalid_tb_cpu_state(target_ulong *pc,
>>>>>                                                  target_ulong *cs_base,
>>>>>                                                  uint32_t *flags)
>>>>>  {
>>>>> -    *cs_base = -1; /* npc must be a multible of 4 */
>>>>> +    *flags = TB_FLAG_MMU_MASK;
>>>>>  }
>>> Hmm, not sure if it is really simpler to follow. Maybe " |= 1;" anyway?
>> |= 1 has the problem that tb_mark_invalid doesn't pass TB's tuple into
>> cpu_get_invalid_tb_cpu_state, and I didn't want to change that.  I'll
>> add a comment,
>>
>>     /* TB_FLAG_MMU_MASK is not a valid MMU index, which makes it is an
>>      * impossible flag combination for valid TBs.
>>      */
>>
> 
> I wonder if using a dedicated field to mark TBs invalid would be so slow
> that we couldn't afford it...

We could, but it would be slower too. :)

"Just make flags=-1 invalid" is probably a valid one too.  There are
many ways to implement it: use less than 32 bits (or equivalently
reserve one bit for invalid TBs), ensure some combos are invalid, etc.
It would probably be valid for all current targets, since no one uses 32
bits.  ARM is the closest to exhausting flag space probably.

Still, I like your patches very much so I'd like to proceed with them,
only with some changes to fix compilation on 32-bit hosts.

Paolo



reply via email to

[Prev in Thread] Current Thread [Next in Thread]