On 10/01/2015 06:05 PM, alvise rigo wrote:
On Wed, Sep 30, 2015 at 10:42 PM, Richard Henderson wrote:
On 09/30/2015 07:46 PM, alvise rigo wrote:
On Wed, Sep 30, 2015 at 5:58 AM, Richard Henderson wrote:
Why would you need to indicate that another cpu has started an exclusive
operation on
On Wed, Sep 30, 2015 at 10:42 PM, Richard Henderson wrote:
>
> On 09/30/2015 07:46 PM, alvise rigo wrote:
>>
>> On Wed, Sep 30, 2015 at 5:58 AM, Richard Henderson wrote:
>>>
>>> Why would you need to indicate that another cpu has started an exclusive
>>> operation on this page? That seems defini
On 09/30/2015 07:46 PM, alvise rigo wrote:
On Wed, Sep 30, 2015 at 5:58 AM, Richard Henderson wrote:
Why would you need to indicate that another cpu has started an exclusive
operation on this page? That seems definitely wrong.
The cpu_physical_memory_clear_excl_dirty() sets the flag to gener
On Wed, Sep 30, 2015 at 5:58 AM, Richard Henderson wrote:
> On 09/24/2015 06:32 PM, Alvise Rigo wrote:
>>
>> The new helpers rely on the legacy ones to perform the actual read/write.
>>
>> The LoadLink helper (helper_ldlink_name) prepares the way for the
>> following SC operation. It sets the link
On 09/24/2015 06:32 PM, Alvise Rigo wrote:
The new helpers rely on the legacy ones to perform the actual read/write.
The LoadLink helper (helper_ldlink_name) prepares the way for the
following SC operation. It sets the linked address and the size of the
access.
These helper also update the TLB e
The new helpers rely on the legacy ones to perform the actual read/write.
The LoadLink helper (helper_ldlink_name) prepares the way for the
following SC operation. It sets the linked address and the size of the
access.
These helper also update the TLB entry of the page involved in the
LL/SC for th
