This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH] powerpc: Update AT_HWCAP2 bits
- From: Adhemerval Zanella <adhemerval dot zanella at linaro dot org>
- To: Tulio Magno Quites Machado Filho <tuliom at linux dot vnet dot ibm dot com>
- Cc: Florian Weimer <fweimer at redhat dot com>, libc-alpha at sourceware dot org
- Date: Thu, 19 Oct 2017 10:11:06 -0200
- Subject: Re: [PATCH] powerpc: Update AT_HWCAP2 bits
- Authentication-results: sourceware.org; auth=none
- References: <20171018191511.20685-1-tuliom@linux.vnet.ibm.com> <480f7d44-f6a5-0de9-f20e-f81513bb88ea@redhat.com>
On 19/10/2017 07:57, Florian Weimer wrote:
> On 10/18/2017 09:15 PM, Tulio Magno Quites Machado Filho wrote:
>> Linux commit ID XXXXXXXXX reserved a new bit for a scenario where
>> transactional memory is available, but the suspended state is disabled.
>
> The semantics of this bit are wrong. If the suspended state is not available, the old hwcap bit needs to be cleared, and a new flag needs to be set which documents the availability of the different for, of transactional memory. Otherwise, old applications which assume the presence of the suspended state when the old hwcap bit is set will break.
>
> (I think we should have this discussion on the kernel list.)
>
> Thanks,
> Florian
How exactly this kind of hardware handles the 'tsr.' instruction
state change? Assuming the kernel submission proposal it seems
an ABI extension, since MSR[TS] will be change from 0xb10 to 0b00
in case of a transaction (instead of expected 0b10 to 0x01).
Will it also execute the failure handling in this case, as for a
'tresume' in the case a failure in suspended state? Also, will
it also change TEXARS with the abort information?
I completely agree with Florian here, this is as *ABI* change
and the kernel need to advertise a different TM ABI instead
of as an extension.