| 1 | /* |
| 2 | * Simple interface for 128-bit atomic operations. |
| 3 | * |
| 4 | * Copyright (C) 2018 Linaro, Ltd. |
| 5 | * |
| 6 | * This work is licensed under the terms of the GNU GPL, version 2 or later. |
| 7 | * See the COPYING file in the top-level directory. |
| 8 | * |
| 9 | * See docs/devel/atomics.rst for discussion about the guarantees each |
| 10 | * atomic primitive is meant to provide. |
| 11 | */ |
| 12 | |
| 13 | #ifndef QEMU_ATOMIC128_H |
| 14 | #define QEMU_ATOMIC128_H |
| 15 | |
| 16 | #include "qemu/atomic.h" |
| 17 | #include "qemu/int128.h" |
| 18 | |
| 19 | /* |
| 20 | * If __alignof(unsigned __int128) < 16, GCC may refuse to inline atomics |
| 21 | * that are supported by the host, e.g. s390x. We can force the pointer to |
| 22 | * have our known alignment with __builtin_assume_aligned, however prior to |
| 23 | * GCC 13 that was only reliable with optimization enabled. See |
| 24 | * https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107389 |
| 25 | */ |
| 26 | #if defined(CONFIG_ATOMIC128_OPT) |
| 27 | # if !defined(__OPTIMIZE__) |
| 28 | # define ATTRIBUTE_ATOMIC128_OPT __attribute__((optimize("O1"))) |
| 29 | # endif |
| 30 | # define CONFIG_ATOMIC128 |
| 31 | #endif |
| 32 | #ifndef ATTRIBUTE_ATOMIC128_OPT |
| 33 | # define ATTRIBUTE_ATOMIC128_OPT |
| 34 | #endif |
| 35 | |
| 36 | /* |
| 37 | * GCC is a house divided about supporting large atomic operations. |
| 38 | * |
| 39 | * For hosts that only have large compare-and-swap, a legalistic reading |
| 40 | * of the C++ standard means that one cannot implement __atomic_read on |
| 41 | * read-only memory, and thus all atomic operations must synchronize |
| 42 | * through libatomic. |
| 43 | * |
| 44 | * See https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80878 |
| 45 | * |
| 46 | * This interpretation is not especially helpful for QEMU. |
| 47 | * For system-mode, all RAM is always read/write from the hypervisor. |
| 48 | * For user-mode, if the guest doesn't implement such an __atomic_read |
| 49 | * then the host need not worry about it either. |
| 50 | * |
| 51 | * Moreover, using libatomic is not an option, because its interface is |
| 52 | * built for std::atomic<T>, and requires that *all* accesses to such an |
| 53 | * object go through the library. In our case we do not have an object |
| 54 | * in the C/C++ sense, but a view of memory as seen by the guest. |
| 55 | * The guest may issue a large atomic operation and then access those |
| 56 | * pieces using word-sized accesses. From the hypervisor, we have no |
| 57 | * way to connect those two actions. |
| 58 | * |
| 59 | * Therefore, special case each platform. |
| 60 | */ |
| 61 | |
| 62 | #include "host/atomic128-cas.h.inc" |
| 63 | #include "host/atomic128-ldst.h.inc" |
| 64 | |
| 65 | #endif /* QEMU_ATOMIC128_H */ |