[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH] xen: Introduce cmpxchg64() and guest_cmpxchg64()
On 20/08/2020 10:25, Jan Beulich wrote:
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?
Right, we would only need to introduce guest_cmpxchg64() for common code.
Cheers,
--
Julien Grall
|
