Re: [PATCH] xen: Introduce cmpxchg64() and guest_cmpxchg64()

[Jan Beulich <jbeulich@xxxxxxxx>]

On 20.08.2020 11:14, Julien Grall wrote:
> 
> 
> On 19/08/2020 10:22, Jan Beulich wrote:
>> On 17.08.2020 15:03, Julien Grall wrote:
>>> On 17/08/2020 12:50, Roger Pau Monné wrote:
>>>> On Mon, Aug 17, 2020 at 12:05:54PM +0100, Julien Grall wrote:
>>>>> The only way I could see to make it work would be to use the same trick as
>>>>> we do for {read, write}_atomic() (see asm-arm/atomic.h). We are using 
>>>>> union
>>>>> and void pointer to prevent explicit cast.
>>>>
>>>> I'm mostly worried about common code having assumed that cmpxchg
>>>> does also handle 64bit sized parameters, and thus failing to use
>>>> cmpxchg64 when required. I assume this is not much of a deal as then
>>>> the Arm 32 build would fail, so it should be fairly easy to catch
>>>> those.
>>> FWIW, this is not very different to the existing approach. If one would
>>> use cmpxchg() with 64-bit, then it would fail to compile.
>>
>> A somewhat related question then: Do you really need both the
>> guest_* and the non-guest variants? Limiting things to plain
>> cmpxchg() would further reduce the risk of someone picking the
>> wrong one without right away noticing the build issue on Arm32.
>> For guest_cmpxchg{,64}() I think there's less of a risk.
> 
> For the IOREQ code, we will need the guest_* version that is built on 
> top of the non-guest variant.
> 
> I would like at least consistency between the two variants. IOW, if we 
> decide to use the name guest_cmpxchg64(), then I would like to use 
> cmpxchg64().

On Arm, that is. There wouldn't be any need to expose cmpxchg64()
for use in common code, and hence not at all on x86, I guess?

Jan