motorhead/qemu
1
0
Fork 0
mirror of https://github.com/Motorhead1991/qemu.git synced 2025-08-02 15:23:53 -06:00
Code Issues Projects Releases Packages Wiki Activity Actions

accel/tcg: Add cpu_{ld,st}*_mmu interfaces

Browse source 
These functions are much closer to the softmmu helper
functions, in that they take the complete MemOpIdx,
and from that they may enforce required alignment.

The previous cpu_ldst.h functions did not have alignment info,
and so did not enforce it.  Retain this by adding MO_UNALN to
the MemOp that we create in calling the new functions.

Note that we are not yet enforcing alignment for user-only,
but we now have the information with which to do so.

Reviewed-by: Peter Maydell <peter.maydell@linaro.org>
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
This commit is contained in:
Richard Henderson 2021-07-27 07:48:55 -10:00
parent f79e80899d
commit f83bcecb1f
5 changed files with 717 additions and 664 deletions
Download patch file Download diff file Expand all files Collapse all files

52
docs/devel/loads-stores.rst
View file

@ -68,15 +68,19 @@ Regexes for git grep
- ``\<ldn_\([hbl]e\)?_p\>``
- ``\<stn_\([hbl]e\)?_p\>``
``cpu_{ld,st}*_mmuidx_ra``
~~~~~~~~~~~~~~~~~~~~~~~~~~
``cpu_{ld,st}*_mmu``
~~~~~~~~~~~~~~~~~~~~
These functions operate on a guest virtual address plus a context,
known as a "mmu index" or ``mmuidx``, which controls how that virtual
address is translated. The meaning of the indexes are target specific,
but specifying a particular index might be necessary if, for instance,
the helper requires an "always as non-privileged" access rather that
the default access for the current state of the guest CPU.
These functions operate on a guest virtual address, plus a context
known as a "mmu index" which controls how that virtual address is
translated, plus a ``MemOp`` which contains alignment requirements
among other things. The ``MemOp`` and mmu index are combined into
a single argument of type ``MemOpIdx``.
The meaning of the indexes are target specific, but specifying a
particular index might be necessary if, for instance, the helper
requires a "always as non-privileged" access rather than the
default access for the current state of the guest CPU.
These functions may cause a guest CPU exception to be taken
(e.g. for an alignment fault or MMU fault) which will result in
@ -99,6 +103,35 @@ function, which is a return address into the generated code [#gpc]_.
Function names follow the pattern:
load: ``cpu_ld{size}{end}_mmu(env, ptr, oi, retaddr)``
store: ``cpu_st{size}{end}_mmu(env, ptr, val, oi, retaddr)``
``size``
- ``b`` : 8 bits
- ``w`` : 16 bits
- ``l`` : 32 bits
- ``q`` : 64 bits
``end``
- (empty) : for target endian, or 8 bit sizes
- ``_be`` : big endian
- ``_le`` : little endian
Regexes for git grep:
- ``\<cpu_ld[bwlq](_[bl]e)\?_mmu\>``
- ``\<cpu_st[bwlq](_[bl]e)\?_mmu\>``
``cpu_{ld,st}*_mmuidx_ra``
~~~~~~~~~~~~~~~~~~~~~~~~~~
These functions work like the ``cpu_{ld,st}_mmu`` functions except
that the ``mmuidx`` parameter is not combined with a ``MemOp``,
and therefore there is no required alignment supplied or enforced.
Function names follow the pattern:
load: ``cpu_ld{sign}{size}{end}_mmuidx_ra(env, ptr, mmuidx, retaddr)``
store: ``cpu_st{size}{end}_mmuidx_ra(env, ptr, val, mmuidx, retaddr)``
@ -132,7 +165,8 @@ of the guest CPU, as determined by ``cpu_mmu_index(env, false)``.
These are generally the preferred way to do accesses by guest
virtual address from helper functions, unless the access should
be performed with a context other than the default.
be performed with a context other than the default, or alignment
should be enforced for the access.
Function names follow the pattern: