| 1 | .. |
| 2 | Copyright (c) 2017 Linaro Limited |
| 3 | Written by Peter Maydell |
| 4 | |
| 5 | =================== |
| 6 | Load and Store APIs |
| 7 | =================== |
| 8 | |
| 9 | QEMU internally has multiple families of functions for performing |
| 10 | loads and stores. This document attempts to enumerate them all |
| 11 | and indicate when to use them. It does not provide detailed |
| 12 | documentation of each API -- for that you should look at the |
| 13 | documentation comments in the relevant header files. |
| 14 | |
| 15 | |
| 16 | ``ld*_p and st*_p`` |
| 17 | ~~~~~~~~~~~~~~~~~~~ |
| 18 | |
| 19 | These functions operate on a host pointer, and should be used |
| 20 | when you already have a pointer into host memory (corresponding |
| 21 | to guest ram or a local buffer). They deal with doing accesses |
| 22 | with the desired endianness and with correctly handling |
| 23 | potentially unaligned pointer values. |
| 24 | |
| 25 | Function names follow the pattern: |
| 26 | |
| 27 | load: ``ld{sign}{size}_{endian}_p(ptr)`` |
| 28 | |
| 29 | store: ``st{size}_{endian}_p(ptr, val)`` |
| 30 | |
| 31 | ``sign`` |
| 32 | - (empty) : for 32 or 64 bit sizes |
| 33 | - ``u`` : unsigned |
| 34 | - ``s`` : signed |
| 35 | |
| 36 | ``size`` |
| 37 | - ``b`` : 8 bits |
| 38 | - ``w`` : 16 bits |
| 39 | - ``24`` : 24 bits |
| 40 | - ``l`` : 32 bits |
| 41 | - ``q`` : 64 bits |
| 42 | |
| 43 | ``endian`` |
| 44 | - ``he`` : host endian |
| 45 | - ``be`` : big endian |
| 46 | - ``le`` : little endian |
| 47 | |
| 48 | The ``_{endian}`` infix is omitted for target-endian accesses. |
| 49 | |
| 50 | The target endian accessors are only available to source |
| 51 | files which are built per-target. |
| 52 | |
| 53 | There are also functions which take the size as an argument: |
| 54 | |
| 55 | load: ``ldn_{endian}_p(ptr, sz)`` |
| 56 | |
| 57 | which performs an unsigned load of ``sz`` bytes from ``ptr`` |
| 58 | as an ``{endian}`` order value and returns it in a uint64_t. |
| 59 | |
| 60 | store: ``stn_{endian}_p(ptr, sz, val)`` |
| 61 | |
| 62 | which stores ``val`` to ``ptr`` as an ``{endian}`` order value |
| 63 | of size ``sz`` bytes. |
| 64 | |
| 65 | |
| 66 | Regexes for git grep: |
| 67 | - ``\<ld[us]\?[bwlq]\(_[hbl]e\)\?_p\>`` |
| 68 | - ``\<st[bwlq]\(_[hbl]e\)\?_p\>`` |
| 69 | - ``\<st24\(_[hbl]e\)\?_p\>`` |
| 70 | - ``\<ldn\(_[hbl]e\)\?_p\>`` |
| 71 | - ``\<stn\(_[hbl]e\)\?_p\>`` |
| 72 | |
| 73 | ``cpu_{ld,st}*_mmu`` |
| 74 | ~~~~~~~~~~~~~~~~~~~~ |
| 75 | |
| 76 | These functions operate on a guest virtual address, plus a context |
| 77 | known as a "mmu index" which controls how that virtual address is |
| 78 | translated, plus a ``MemOp`` which contains alignment requirements |
| 79 | among other things. The ``MemOp`` and mmu index are combined into |
| 80 | a single argument of type ``MemOpIdx``. |
| 81 | |
| 82 | The meaning of the indexes are target specific, but specifying a |
| 83 | particular index might be necessary if, for instance, the helper |
| 84 | requires a "always as non-privileged" access rather than the |
| 85 | default access for the current state of the guest CPU. |
| 86 | |
| 87 | These functions may cause a guest CPU exception to be taken |
| 88 | (e.g. for an alignment fault or MMU fault) which will result in |
| 89 | guest CPU state being updated and control longjmp'ing out of the |
| 90 | function call. They should therefore only be used in code that is |
| 91 | implementing emulation of the guest CPU. |
| 92 | |
| 93 | The ``retaddr`` parameter is used to control unwinding of the |
| 94 | guest CPU state in case of a guest CPU exception. This is passed |
| 95 | to ``cpu_restore_state()``. Therefore the value should either be 0, |
| 96 | to indicate that the guest CPU state is already synchronized, or |
| 97 | the result of ``GETPC()`` from the top level ``HELPER(foo)`` |
| 98 | function, which is a return address into the generated code\ [#gpc]_. |
| 99 | |
| 100 | .. [#gpc] Note that ``GETPC()`` should be used with great care: calling |
| 101 | it in other functions that are *not* the top level |
| 102 | ``HELPER(foo)`` will cause unexpected behavior. Instead, the |
| 103 | value of ``GETPC()`` should be read from the helper and passed |
| 104 | if needed to the functions that the helper calls. |
| 105 | |
| 106 | Function names follow the pattern: |
| 107 | |
| 108 | load: ``cpu_ld{size}{end}_mmu(env, ptr, oi, retaddr)`` |
| 109 | |
| 110 | store: ``cpu_st{size}{end}_mmu(env, ptr, val, oi, retaddr)`` |
| 111 | |
| 112 | ``size`` |
| 113 | - ``b`` : 8 bits |
| 114 | - ``w`` : 16 bits |
| 115 | - ``l`` : 32 bits |
| 116 | - ``q`` : 64 bits |
| 117 | |
| 118 | ``end`` |
| 119 | - (empty) : for target endian, or 8 bit sizes |
| 120 | - ``_be`` : big endian |
| 121 | - ``_le`` : little endian |
| 122 | |
| 123 | Regexes for git grep: |
| 124 | - ``\<cpu_ld[bwlq]\(_[bl]e\)\?_mmu\>`` |
| 125 | - ``\<cpu_st[bwlq]\(_[bl]e\)\?_mmu\>`` |
| 126 | |
| 127 | |
| 128 | ``cpu_{ld,st}*_mmuidx_ra`` |
| 129 | ~~~~~~~~~~~~~~~~~~~~~~~~~~ |
| 130 | |
| 131 | These functions work like the ``cpu_{ld,st}_mmu`` functions except |
| 132 | that the ``mmuidx`` parameter is not combined with a ``MemOp``, |
| 133 | and therefore there is no required alignment supplied or enforced. |
| 134 | |
| 135 | Function names follow the pattern: |
| 136 | |
| 137 | load: ``cpu_ld{sign}{size}{end}_mmuidx_ra(env, ptr, mmuidx, retaddr)`` |
| 138 | |
| 139 | store: ``cpu_st{size}{end}_mmuidx_ra(env, ptr, val, mmuidx, retaddr)`` |
| 140 | |
| 141 | ``sign`` |
| 142 | - (empty) : for 32 or 64 bit sizes |
| 143 | - ``u`` : unsigned |
| 144 | - ``s`` : signed |
| 145 | |
| 146 | ``size`` |
| 147 | - ``b`` : 8 bits |
| 148 | - ``w`` : 16 bits |
| 149 | - ``l`` : 32 bits |
| 150 | - ``q`` : 64 bits |
| 151 | |
| 152 | ``end`` |
| 153 | - (empty) : for target endian, or 8 bit sizes |
| 154 | - ``_be`` : big endian |
| 155 | - ``_le`` : little endian |
| 156 | |
| 157 | Regexes for git grep: |
| 158 | - ``\<cpu_ld[us]\?[bwlq]\(_[bl]e\)\?_mmuidx_ra\>`` |
| 159 | - ``\<cpu_st[bwlq]\(_[bl]e\)\?_mmuidx_ra\>`` |
| 160 | |
| 161 | ``cpu_{ld,st}*_data_ra`` |
| 162 | ~~~~~~~~~~~~~~~~~~~~~~~~ |
| 163 | |
| 164 | These functions work like the ``cpu_{ld,st}_mmuidx_ra`` functions |
| 165 | except that the ``mmuidx`` parameter is taken from the current mode |
| 166 | of the guest CPU, as determined by ``cpu_mmu_index(env, false)``. |
| 167 | |
| 168 | These are generally the preferred way to do accesses by guest |
| 169 | virtual address from helper functions, unless the access should |
| 170 | be performed with a context other than the default, or alignment |
| 171 | should be enforced for the access. |
| 172 | |
| 173 | Function names follow the pattern: |
| 174 | |
| 175 | load: ``cpu_ld{sign}{size}{end}_data_ra(env, ptr, ra)`` |
| 176 | |
| 177 | store: ``cpu_st{size}{end}_data_ra(env, ptr, val, ra)`` |
| 178 | |
| 179 | ``sign`` |
| 180 | - (empty) : for 32 or 64 bit sizes |
| 181 | - ``u`` : unsigned |
| 182 | - ``s`` : signed |
| 183 | |
| 184 | ``size`` |
| 185 | - ``b`` : 8 bits |
| 186 | - ``w`` : 16 bits |
| 187 | - ``l`` : 32 bits |
| 188 | - ``q`` : 64 bits |
| 189 | |
| 190 | ``end`` |
| 191 | - (empty) : for target endian, or 8 bit sizes |
| 192 | - ``_be`` : big endian |
| 193 | - ``_le`` : little endian |
| 194 | |
| 195 | Regexes for git grep: |
| 196 | - ``\<cpu_ld[us]\?[bwlq]\(_[bl]e\)\?_data_ra\>`` |
| 197 | - ``\<cpu_st[bwlq]\(_[bl]e\)\?_data_ra\>`` |
| 198 | |
| 199 | ``cpu_{ld,st}*_data`` |
| 200 | ~~~~~~~~~~~~~~~~~~~~~ |
| 201 | |
| 202 | These functions work like the ``cpu_{ld,st}_data_ra`` functions |
| 203 | except that the ``retaddr`` parameter is 0, and thus does not |
| 204 | unwind guest CPU state. |
| 205 | |
| 206 | This means they must only be used from helper functions where the |
| 207 | translator has saved all necessary CPU state. These functions are |
| 208 | the right choice for calls made from hooks like the CPU ``do_interrupt`` |
| 209 | hook or when you know for certain that the translator had to save all |
| 210 | the CPU state anyway. |
| 211 | |
| 212 | Function names follow the pattern: |
| 213 | |
| 214 | load: ``cpu_ld{sign}{size}{end}_data(env, ptr)`` |
| 215 | |
| 216 | store: ``cpu_st{size}{end}_data(env, ptr, val)`` |
| 217 | |
| 218 | ``sign`` |
| 219 | - (empty) : for 32 or 64 bit sizes |
| 220 | - ``u`` : unsigned |
| 221 | - ``s`` : signed |
| 222 | |
| 223 | ``size`` |
| 224 | - ``b`` : 8 bits |
| 225 | - ``w`` : 16 bits |
| 226 | - ``l`` : 32 bits |
| 227 | - ``q`` : 64 bits |
| 228 | |
| 229 | ``end`` |
| 230 | - (empty) : for target endian, or 8 bit sizes |
| 231 | - ``_be`` : big endian |
| 232 | - ``_le`` : little endian |
| 233 | |
| 234 | Regexes for git grep: |
| 235 | - ``\<cpu_ld[us]\?[bwlq]\(_[bl]e\)\?_data\>`` |
| 236 | - ``\<cpu_st[bwlq]\(_[bl]e\)\?_data\+\>`` |
| 237 | |
| 238 | ``cpu_ld*_code_mmu`` |
| 239 | ~~~~~~~~~~~~~~~~~~~~ |
| 240 | |
| 241 | These functions work like the ``cpu_{ld,st}*_mmu`` functions |
| 242 | except that they perform a read for instruction execution. |
| 243 | Any guest CPU exception that is raised will indicate an instruction |
| 244 | execution fault rather than a data read fault. |
| 245 | |
| 246 | In general these functions should not be used directly during translation. |
| 247 | There are wrapper functions that are to be used which also take care of |
| 248 | plugins for tracing. |
| 249 | |
| 250 | Function names follow the pattern: |
| 251 | |
| 252 | load: ``cpu_ld{sign}{size}_code_mmu(env, addr, oi, retaddr)`` |
| 253 | |
| 254 | ``sign`` |
| 255 | - (empty) : for 32 or 64 bit sizes |
| 256 | - ``u`` : unsigned |
| 257 | - ``s`` : signed |
| 258 | |
| 259 | ``size`` |
| 260 | - ``b`` : 8 bits |
| 261 | - ``w`` : 16 bits |
| 262 | - ``l`` : 32 bits |
| 263 | - ``q`` : 64 bits |
| 264 | |
| 265 | Regexes for git grep: |
| 266 | - ``\<cpu_ld[us]\?[bwlq]_code_mmu\>`` |
| 267 | |
| 268 | ``translator_ld*`` |
| 269 | ~~~~~~~~~~~~~~~~~~ |
| 270 | |
| 271 | These functions are a wrapper for ``cpu_ld*_code_mmu`` which also perform |
| 272 | any actions required by any tracing plugins. They are only to be |
| 273 | called during the translator callback ``translate_insn``. |
| 274 | |
| 275 | There is a set of functions ending in ``_swap`` which, if the parameter |
| 276 | is true, returns the value in the endianness that is the reverse of |
| 277 | the guest native endianness, as determined by ``TARGET_BIG_ENDIAN``. |
| 278 | |
| 279 | Function names follow the pattern: |
| 280 | |
| 281 | load: ``translator_ld{sign}{size}(env, ptr)`` |
| 282 | |
| 283 | swap: ``translator_ld{sign}{size}_swap(env, ptr, swap)`` |
| 284 | |
| 285 | ``sign`` |
| 286 | - (empty) : for 32 or 64 bit sizes |
| 287 | - ``u`` : unsigned |
| 288 | - ``s`` : signed |
| 289 | |
| 290 | ``size`` |
| 291 | - ``b`` : 8 bits |
| 292 | - ``w`` : 16 bits |
| 293 | - ``l`` : 32 bits |
| 294 | - ``q`` : 64 bits |
| 295 | |
| 296 | Regexes for git grep: |
| 297 | - ``\<translator_ld[us]\?[bwlq]\(_swap\)\?\>`` |
| 298 | |
| 299 | ``helper_{ld,st}*_mmu`` |
| 300 | ~~~~~~~~~~~~~~~~~~~~~~~~~ |
| 301 | |
| 302 | These functions are intended primarily to be called by the code |
| 303 | generated by the TCG backend. Like the ``cpu_{ld,st}_mmu`` functions |
| 304 | they perform accesses by guest virtual address, with a given ``MemOpIdx``. |
| 305 | |
| 306 | They differ from ``cpu_{ld,st}_mmu`` in that they take the endianness |
| 307 | of the operation only from the MemOpIdx, and loads extend the return |
| 308 | value to the size of a host general register (``tcg_target_ulong``). |
| 309 | |
| 310 | load: ``helper_ld{sign}{size}_mmu(env, addr, opindex, retaddr)`` |
| 311 | |
| 312 | store: ``helper_{size}_mmu(env, addr, val, opindex, retaddr)`` |
| 313 | |
| 314 | ``sign`` |
| 315 | - (empty) : for 32 or 64 bit sizes |
| 316 | - ``u`` : unsigned |
| 317 | - ``s`` : signed |
| 318 | |
| 319 | ``size`` |
| 320 | - ``b`` : 8 bits |
| 321 | - ``w`` : 16 bits |
| 322 | - ``l`` : 32 bits |
| 323 | - ``q`` : 64 bits |
| 324 | |
| 325 | Regexes for git grep: |
| 326 | - ``\<helper_ld[us]\?[bwlq]_mmu\>`` |
| 327 | - ``\<helper_st[bwlq]_mmu\>`` |
| 328 | |
| 329 | ``address_space_*`` |
| 330 | ~~~~~~~~~~~~~~~~~~~ |
| 331 | |
| 332 | These functions are the primary ones to use when emulating CPU |
| 333 | or device memory accesses. They take an AddressSpace, which is the |
| 334 | way QEMU defines the view of memory that a device or CPU has. |
| 335 | (They generally correspond to being the "master" end of a hardware bus |
| 336 | or bus fabric.) |
| 337 | |
| 338 | Each CPU has an AddressSpace. Some kinds of CPU have more than |
| 339 | one AddressSpace (for instance Arm guest CPUs have an AddressSpace |
| 340 | for the Secure world and one for NonSecure if they implement TrustZone). |
| 341 | Devices which can do DMA-type operations should generally have an |
| 342 | AddressSpace. There is also a "system address space" which typically |
| 343 | has all the devices and memory that all CPUs can see. (Some older |
| 344 | device models use the "system address space" rather than properly |
| 345 | modelling that they have an AddressSpace of their own.) |
| 346 | |
| 347 | Functions are provided for doing byte-buffer reads and writes, |
| 348 | and also for doing one-data-item loads and stores. |
| 349 | |
| 350 | In all cases the caller provides a MemTxAttrs to specify bus |
| 351 | transaction attributes, and can check whether the memory transaction |
| 352 | succeeded using a MemTxResult return code. |
| 353 | |
| 354 | ``address_space_read(address_space, addr, attrs, buf, len)`` |
| 355 | |
| 356 | ``address_space_write(address_space, addr, attrs, buf, len)`` |
| 357 | |
| 358 | ``address_space_rw(address_space, addr, attrs, buf, len, is_write)`` |
| 359 | |
| 360 | ``address_space_ld{sign}{size}_{endian}(address_space, addr, attrs, txresult)`` |
| 361 | |
| 362 | ``address_space_st{size}_{endian}(address_space, addr, val, attrs, txresult)`` |
| 363 | |
| 364 | ``sign`` |
| 365 | - (empty) : for 32 or 64 bit sizes |
| 366 | - ``u`` : unsigned |
| 367 | |
| 368 | (No signed load operations are provided.) |
| 369 | |
| 370 | ``size`` |
| 371 | - ``b`` : 8 bits |
| 372 | - ``w`` : 16 bits |
| 373 | - ``l`` : 32 bits |
| 374 | - ``q`` : 64 bits |
| 375 | |
| 376 | ``endian`` |
| 377 | - ``le`` : little endian |
| 378 | - ``be`` : big endian |
| 379 | |
| 380 | The ``_{endian}`` suffix is omitted for byte accesses. |
| 381 | |
| 382 | Regexes for git grep: |
| 383 | - ``\<address_space_\(read\|write\|rw\)\>`` |
| 384 | - ``\<address_space_ldu\?[bwql]\(_[lb]e\)\?\>`` |
| 385 | - ``\<address_space_st[bwql]\(_[lb]e\)\?\>`` |
| 386 | |
| 387 | ``address_space_write_rom`` |
| 388 | ~~~~~~~~~~~~~~~~~~~~~~~~~~~ |
| 389 | |
| 390 | This function performs a write by physical address like |
| 391 | ``address_space_write``, except that if the write is to a ROM then |
| 392 | the ROM contents will be modified, even though a write by the guest |
| 393 | CPU to the ROM would be ignored. This is used for non-guest writes |
| 394 | like writes from the gdb debug stub or initial loading of ROM contents. |
| 395 | |
| 396 | Note that portions of the write which attempt to write data to a |
| 397 | device will be silently ignored -- only real RAM and ROM will |
| 398 | be written to. |
| 399 | |
| 400 | Regexes for git grep: |
| 401 | - ``address_space_write_rom`` |
| 402 | |
| 403 | ``{ld,st}*_phys`` |
| 404 | ~~~~~~~~~~~~~~~~~ |
| 405 | |
| 406 | These are functions which are identical to |
| 407 | ``address_space_{ld,st}*``, except that they always pass |
| 408 | ``MEMTXATTRS_UNSPECIFIED`` for the transaction attributes, and ignore |
| 409 | whether the transaction succeeded or failed. |
| 410 | |
| 411 | The fact that they ignore whether the transaction succeeded means |
| 412 | they should not be used in new code, unless you know for certain |
| 413 | that your code will only be used in a context where the CPU or |
| 414 | device doing the access has no way to report such an error. |
| 415 | |
| 416 | ``load: ld{sign}{size}_{endian}_phys`` |
| 417 | |
| 418 | ``store: st{size}_{endian}_phys`` |
| 419 | |
| 420 | ``sign`` |
| 421 | - (empty) : for 32 or 64 bit sizes |
| 422 | - ``u`` : unsigned |
| 423 | |
| 424 | (No signed load operations are provided.) |
| 425 | |
| 426 | ``size`` |
| 427 | - ``b`` : 8 bits |
| 428 | - ``w`` : 16 bits |
| 429 | - ``l`` : 32 bits |
| 430 | - ``q`` : 64 bits |
| 431 | |
| 432 | ``endian`` |
| 433 | - ``le`` : little endian |
| 434 | - ``be`` : big endian |
| 435 | |
| 436 | The ``_{endian}_`` infix is omitted for byte accesses. |
| 437 | |
| 438 | Regexes for git grep: |
| 439 | - ``\<ldu\?[bwlq]\(_[bl]e\)\?_phys\>`` |
| 440 | - ``\<st[bwlq]\(_[bl]e\)\?_phys\>`` |
| 441 | |
| 442 | ``physical_memory_*`` |
| 443 | ~~~~~~~~~~~~~~~~~~~~~~~~~ |
| 444 | |
| 445 | These are convenience functions which are identical to |
| 446 | ``address_space_*`` but operate specifically on the legacy global |
| 447 | ``&address_space_memory`` address space (which might not be used by all |
| 448 | machines), always pass a ``MEMTXATTRS_UNSPECIFIED`` set of memory attributes |
| 449 | and ignore whether the memory transaction succeeded or failed. Expected |
| 450 | users are hardware device models. For new code they are better avoided: |
| 451 | |
| 452 | * there is likely to be behaviour you need to model correctly for a |
| 453 | failed read or write operation |
| 454 | * a device should usually perform operations on its own AddressSpace |
| 455 | rather than using the system address space |
| 456 | * some machines do not use this global address space at all |
| 457 | |
| 458 | ``physical_memory_read`` |
| 459 | |
| 460 | ``physical_memory_write`` |
| 461 | |
| 462 | Regexes for git grep: |
| 463 | - ``\<physical_memory_\(read\|write\)\>`` |
| 464 | |
| 465 | ``cpu_memory_rw_debug`` |
| 466 | ~~~~~~~~~~~~~~~~~~~~~~~ |
| 467 | |
| 468 | Access CPU memory by virtual address for debug purposes. |
| 469 | |
| 470 | This function is intended for use by the GDB stub and similar code. |
| 471 | It takes a virtual address, converts it to a physical address via |
| 472 | an MMU lookup using the current settings of the specified CPU, |
| 473 | and then performs the access (using ``address_space_rw`` for |
| 474 | reads or ``address_space_write_rom`` for writes). |
| 475 | This means that if the access is a write to a ROM then this |
| 476 | function will modify the contents (whereas a normal guest CPU access |
| 477 | would ignore the write attempt). |
| 478 | |
| 479 | ``cpu_memory_rw_debug`` |
| 480 | |
| 481 | ``dma_memory_*`` |
| 482 | ~~~~~~~~~~~~~~~~ |
| 483 | |
| 484 | These behave like ``address_space_*``, except that they perform a DMA |
| 485 | barrier operation first. |
| 486 | |
| 487 | **TODO**: We should provide guidance on when you need the DMA |
| 488 | barrier operation and when it's OK to use ``address_space_*``, and |
| 489 | make sure our existing code is doing things correctly. |
| 490 | |
| 491 | ``dma_memory_read`` |
| 492 | |
| 493 | ``dma_memory_write`` |
| 494 | |
| 495 | ``dma_memory_rw`` |
| 496 | |
| 497 | Regexes for git grep: |
| 498 | - ``\<dma_memory_\(read\|write\|rw\)\>`` |
| 499 | - ``\<ldu\?[bwlq]\(_[bl]e\)\?_dma\>`` |
| 500 | - ``\<st[bwlq]\(_[bl]e\)\?_dma\>`` |
| 501 | |
| 502 | ``pci_dma_*`` and ``{ld,st}*_pci_dma`` |
| 503 | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ |
| 504 | |
| 505 | These functions are specifically for PCI device models which need to |
| 506 | perform accesses where the PCI device is a bus master. You pass them a |
| 507 | ``PCIDevice *`` and they will do ``dma_memory_*`` operations on the |
| 508 | correct address space for that device. |
| 509 | |
| 510 | ``pci_dma_read`` |
| 511 | |
| 512 | ``pci_dma_write`` |
| 513 | |
| 514 | ``pci_dma_rw`` |
| 515 | |
| 516 | ``load: ld{sign}{size}_{endian}_pci_dma`` |
| 517 | |
| 518 | ``store: st{size}_{endian}_pci_dma`` |
| 519 | |
| 520 | ``sign`` |
| 521 | - (empty) : for 32 or 64 bit sizes |
| 522 | - ``u`` : unsigned |
| 523 | |
| 524 | (No signed load operations are provided.) |
| 525 | |
| 526 | ``size`` |
| 527 | - ``b`` : 8 bits |
| 528 | - ``w`` : 16 bits |
| 529 | - ``l`` : 32 bits |
| 530 | - ``q`` : 64 bits |
| 531 | |
| 532 | ``endian`` |
| 533 | - ``le`` : little endian |
| 534 | - ``be`` : big endian |
| 535 | |
| 536 | The ``_{endian}_`` infix is omitted for byte accesses. |
| 537 | |
| 538 | Regexes for git grep: |
| 539 | - ``\<pci_dma_\(read\|write\|rw\)\>`` |
| 540 | - ``\<ldu\?[bwlq]\(_[bl]e\)\?_pci_dma\>`` |
| 541 | - ``\<st[bwlq]\(_[bl]e\)\?_pci_dma\>`` |