jcs.org
qemu with hax to log dma reads & writes
jcs.org/2018/11/12/vfio
cputlb: Provide cpu_(ld,st}*_mmuidx_ra for user-only
This finishes the new interface began with the previous patch.
Document the interface and deprecate MMU_MODE<N>_SUFFIX.
Tested-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Reviewed-by: Aleksandar Markovic <amarkovic@wavecomp.com>
Reviewed-by: Alex Bennée <alex.bennee@linaro.org>
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
+228
-59
+153
-54
docs/devel/loads-stores.rst
+153
-54
docs/devel/loads-stores.rst
···
72
72
- ``\<ldn_\([hbl]e\)?_p\>``
73
73
- ``\<stn_\([hbl]e\)?_p\>``
74
74
75
-
``cpu_{ld,st}_*``
76
-
~~~~~~~~~~~~~~~~~
75
+
``cpu_{ld,st}*_mmuidx_ra``
76
+
~~~~~~~~~~~~~~~~~~~~~~~~~~
77
77
78
-
These functions operate on a guest virtual address. Be aware
79
-
that these functions may cause a guest CPU exception to be
80
-
taken (e.g. for an alignment fault or MMU fault) which will
81
-
result in guest CPU state being updated and control longjumping
82
-
out of the function call. They should therefore only be used
83
-
in code that is implementing emulation of the target CPU.
78
+
These functions operate on a guest virtual address plus a context,
79
+
known as a "mmu index" or ``mmuidx``, which controls how that virtual
80
+
address is translated. The meaning of the indexes are target specific,
81
+
but specifying a particular index might be necessary if, for instance,
82
+
the helper requires an "always as non-privileged" access rather that
83
+
the default access for the current state of the guest CPU.
84
84
85
-
These functions may throw an exception (longjmp() back out
86
-
to the top level TCG loop). This means they must only be used
87
-
from helper functions where the translator has saved all
88
-
necessary CPU state before generating the helper function call.
89
-
It's usually better to use the ``_ra`` variants described below
90
-
from helper functions, but these functions are the right choice
91
-
for calls made from hooks like the CPU do_interrupt hook or
92
-
when you know for certain that the translator had to save all
93
-
the CPU state that ``cpu_restore_state()`` would restore anyway.
85
+
These functions may cause a guest CPU exception to be taken
86
+
(e.g. for an alignment fault or MMU fault) which will result in
87
+
guest CPU state being updated and control longjmp'ing out of the
88
+
function call. They should therefore only be used in code that is
89
+
implementing emulation of the guest CPU.
90
+
91
+
The ``retaddr`` parameter is used to control unwinding of the
92
+
guest CPU state in case of a guest CPU exception. This is passed
93
+
to ``cpu_restore_state()``. Therefore the value should either be 0,
94
+
to indicate that the guest CPU state is already synchronized, or
95
+
the result of ``GETPC()`` from the top level ``HELPER(foo)``
96
+
function, which is a return address into the generated code.
94
97
95
98
Function names follow the pattern:
96
99
97
-
load: ``cpu_ld{sign}{size}_{mmusuffix}(env, ptr)``
100
+
load: ``cpu_ld{sign}{size}_mmuidx_ra(env, ptr, mmuidx, retaddr)``
98
101
99
-
store: ``cpu_st{size}_{mmusuffix}(env, ptr, val)``
102
+
store: ``cpu_st{size}_mmuidx_ra(env, ptr, val, mmuidx, retaddr)``
100
103
101
104
``sign``
102
105
- (empty) : for 32 or 64 bit sizes
···
109
112
- ``l`` : 32 bits
110
113
- ``q`` : 64 bits
111
114
112
-
``mmusuffix`` is one of the generic suffixes ``data`` or ``code``, or
113
-
(for softmmu configs) a target-specific MMU mode suffix as defined
114
-
in the target's ``cpu.h``.
115
+
Regexes for git grep:
116
+
- ``\<cpu_ld[us]\?[bwlq]_mmuidx_ra\>``
117
+
- ``\<cpu_st[bwlq]_mmuidx_ra\>``
118
+
119
+
``cpu_{ld,st}*_data_ra``
120
+
~~~~~~~~~~~~~~~~~~~~~~~~
121
+
122
+
These functions work like the ``cpu_{ld,st}_mmuidx_ra`` functions
123
+
except that the ``mmuidx`` parameter is taken from the current mode
124
+
of the guest CPU, as determined by ``cpu_mmu_index(env, false)``.
125
+
126
+
These are generally the preferred way to do accesses by guest
127
+
virtual address from helper functions, unless the access should
128
+
be performed with a context other than the default.
129
+
130
+
Function names follow the pattern:
131
+
132
+
load: ``cpu_ld{sign}{size}_data_ra(env, ptr, ra)``
133
+
134
+
store: ``cpu_st{size}_data_ra(env, ptr, val, ra)``
135
+
136
+
``sign``
137
+
- (empty) : for 32 or 64 bit sizes
138
+
- ``u`` : unsigned
139
+
- ``s`` : signed
140
+
141
+
``size``
142
+
- ``b`` : 8 bits
143
+
- ``w`` : 16 bits
144
+
- ``l`` : 32 bits
145
+
- ``q`` : 64 bits
146
+
147
+
Regexes for git grep:
148
+
- ``\<cpu_ld[us]\?[bwlq]_data_ra\>``
149
+
- ``\<cpu_st[bwlq]_data_ra\>``
150
+
151
+
``cpu_{ld,st}*_data``
152
+
~~~~~~~~~~~~~~~~~~~~~
153
+
154
+
These functions work like the ``cpu_{ld,st}_data_ra`` functions
155
+
except that the ``retaddr`` parameter is 0, and thus does not
156
+
unwind guest CPU state.
157
+
158
+
This means they must only be used from helper functions where the
159
+
translator has saved all necessary CPU state. These functions are
160
+
the right choice for calls made from hooks like the CPU ``do_interrupt``
161
+
hook or when you know for certain that the translator had to save all
162
+
the CPU state anyway.
163
+
164
+
Function names follow the pattern:
165
+
166
+
load: ``cpu_ld{sign}{size}_data(env, ptr)``
167
+
168
+
store: ``cpu_st{size}_data(env, ptr, val)``
169
+
170
+
``sign``
171
+
- (empty) : for 32 or 64 bit sizes
172
+
- ``u`` : unsigned
173
+
- ``s`` : signed
174
+
175
+
``size``
176
+
- ``b`` : 8 bits
177
+
- ``w`` : 16 bits
178
+
- ``l`` : 32 bits
179
+
- ``q`` : 64 bits
115
180
116
181
Regexes for git grep
117
-
- ``\<cpu_ld[us]\?[bwlq]_[a-zA-Z0-9]\+\>``
118
-
- ``\<cpu_st[bwlq]_[a-zA-Z0-9]\+\>``
182
+
- ``\<cpu_ld[us]\?[bwlq]_data\>``
183
+
- ``\<cpu_st[bwlq]_data\+\>``
119
184
120
-
``cpu_{ld,st}_*_ra``
121
-
~~~~~~~~~~~~~~~~~~~~
185
+
``cpu_ld*_code``
186
+
~~~~~~~~~~~~~~~~
122
187
123
-
These functions work like the ``cpu_{ld,st}_*`` functions except
124
-
that they also take a ``retaddr`` argument. This extra argument
125
-
allows for correct unwinding of any exception that is taken,
126
-
and should generally be the result of GETPC() called directly
127
-
from the top level HELPER(foo) function (i.e. the return address
128
-
in the generated code).
188
+
These functions perform a read for instruction execution. The ``mmuidx``
189
+
parameter is taken from the current mode of the guest CPU, as determined
190
+
by ``cpu_mmu_index(env, true)``. The ``retaddr`` parameter is 0, and
191
+
thus does not unwind guest CPU state, because CPU state is always
192
+
synchronized while translating instructions. Any guest CPU exception
193
+
that is raised will indicate an instruction execution fault rather than
194
+
a data read fault.
129
195
130
-
These are generally the preferred way to do accesses by guest
131
-
virtual address from helper functions; see the documentation
132
-
of the non-``_ra`` variants for when those would be better.
196
+
In general these functions should not be used directly during translation.
197
+
There are wrapper functions that are to be used which also take care of
198
+
plugins for tracing.
199
+
200
+
Function names follow the pattern:
201
+
202
+
load: ``cpu_ld{sign}{size}_code(env, ptr)``
203
+
204
+
``sign``
205
+
- (empty) : for 32 or 64 bit sizes
206
+
- ``u`` : unsigned
207
+
- ``s`` : signed
208
+
209
+
``size``
210
+
- ``b`` : 8 bits
211
+
- ``w`` : 16 bits
212
+
- ``l`` : 32 bits
213
+
- ``q`` : 64 bits
214
+
215
+
Regexes for git grep:
216
+
- ``\<cpu_ld[us]\?[bwlq]_code\>``
217
+
218
+
``translator_ld*``
219
+
~~~~~~~~~~~~~~~~~~
220
+
221
+
These functions are a wrapper for ``cpu_ld*_code`` which also perform
222
+
any actions required by any tracing plugins. They are only to be
223
+
called during the translator callback ``translate_insn``.
133
224
134
-
Calling these functions with a ``retaddr`` argument of 0 is
135
-
equivalent to calling the non-``_ra`` version of the function.
225
+
There is a set of functions ending in ``_swap`` which, if the parameter
226
+
is true, returns the value in the endianness that is the reverse of
227
+
the guest native endianness, as determined by ``TARGET_WORDS_BIGENDIAN``.
136
228
137
229
Function names follow the pattern:
138
230
139
-
load: ``cpu_ld{sign}{size}_{mmusuffix}_ra(env, ptr, retaddr)``
231
+
load: ``translator_ld{sign}{size}(env, ptr)``
140
232
141
-
store: ``cpu_st{sign}{size}_{mmusuffix}_ra(env, ptr, val, retaddr)``
233
+
swap: ``translator_ld{sign}{size}_swap(env, ptr, swap)``
234
+
235
+
``sign``
236
+
- (empty) : for 32 or 64 bit sizes
237
+
- ``u`` : unsigned
238
+
- ``s`` : signed
239
+
240
+
``size``
241
+
- ``b`` : 8 bits
242
+
- ``w`` : 16 bits
243
+
- ``l`` : 32 bits
244
+
- ``q`` : 64 bits
142
245
143
246
Regexes for git grep
144
-
- ``\<cpu_ld[us]\?[bwlq]_[a-zA-Z0-9]\+_ra\>``
145
-
- ``\<cpu_st[bwlq]_[a-zA-Z0-9]\+_ra\>``
247
+
- ``\<translator_ld[us]\?[bwlq]\(_swap\)\?\>``
146
248
147
-
``helper_*_{ld,st}*mmu``
148
-
~~~~~~~~~~~~~~~~~~~~~~~~
249
+
``helper_*_{ld,st}*_mmu``
250
+
~~~~~~~~~~~~~~~~~~~~~~~~~
149
251
150
252
These functions are intended primarily to be called by the code
151
253
generated by the TCG backend. They may also be called by target
152
-
CPU helper function code. Like the ``cpu_{ld,st}_*_ra`` functions
153
-
they perform accesses by guest virtual address; the difference is
154
-
that these functions allow you to specify an ``opindex`` parameter
155
-
which encodes (among other things) the mmu index to use for the
156
-
access. This is necessary if your helper needs to make an access
157
-
via a specific mmu index (for instance, an "always as non-privileged"
158
-
access) rather than using the default mmu index for the current state
159
-
of the guest CPU.
254
+
CPU helper function code. Like the ``cpu_{ld,st}_mmuidx_ra`` functions
255
+
they perform accesses by guest virtual address, with a given ``mmuidx``.
160
256
161
-
The ``opindex`` parameter should be created by calling ``make_memop_idx()``.
257
+
These functions specify an ``opindex`` parameter which encodes
258
+
(among other things) the mmu index to use for the access. This parameter
259
+
should be created by calling ``make_memop_idx()``.
162
260
163
261
The ``retaddr`` parameter should be the result of GETPC() called directly
164
262
from the top level HELPER(foo) function (or 0 if no guest CPU state
···
166
264
167
265
**TODO** The names of these functions are a bit odd for historical
168
266
reasons because they were originally expected to be called only from
169
-
within generated code. We should rename them to bring them
170
-
more in line with the other memory access functions.
267
+
within generated code. We should rename them to bring them more in
268
+
line with the other memory access functions. The explicit endianness
269
+
is the only feature they have beyond ``*_mmuidx_ra``.
171
270
172
271
load: ``helper_{endian}_ld{sign}{size}_mmu(env, addr, opindex, retaddr)``
173
272
+75
-5
include/exec/cpu_ldst.h
+75
-5
include/exec/cpu_ldst.h
···
25
25
*
26
26
* The syntax for the accessors is:
27
27
*
28
-
* load: cpu_ld{sign}{size}_{mmusuffix}(env, ptr)
28
+
* load: cpu_ld{sign}{size}_{mmusuffix}(env, ptr)
29
+
* cpu_ld{sign}{size}_{mmusuffix}_ra(env, ptr, retaddr)
30
+
* cpu_ld{sign}{size}_mmuidx_ra(env, ptr, mmu_idx, retaddr)
29
31
*
30
-
* store: cpu_st{sign}{size}_{mmusuffix}(env, ptr, val)
32
+
* store: cpu_st{size}_{mmusuffix}(env, ptr, val)
33
+
* cpu_st{size}_{mmusuffix}_ra(env, ptr, val, retaddr)
34
+
* cpu_st{size}_mmuidx_ra(env, ptr, val, mmu_idx, retaddr)
31
35
*
32
36
* sign is:
33
37
* (empty): for 32 and 64 bit sizes
···
40
44
* l: 32 bits
41
45
* q: 64 bits
42
46
*
43
-
* mmusuffix is one of the generic suffixes "data" or "code", or
44
-
* (for softmmu configs) a target-specific MMU mode suffix as defined
45
-
* in target cpu.h.
47
+
* mmusuffix is one of the generic suffixes "data" or "code", or "mmuidx".
48
+
* The "mmuidx" suffix carries an extra mmu_idx argument that specifies
49
+
* the index to use; the "data" and "code" suffixes take the index from
50
+
* cpu_mmu_index().
46
51
*/
47
52
#ifndef CPU_LDST_H
48
53
#define CPU_LDST_H
···
144
149
#include "exec/cpu_ldst_useronly_template.h"
145
150
#undef MEMSUFFIX
146
151
#undef CODE_ACCESS
152
+
153
+
/*
154
+
* Provide the same *_mmuidx_ra interface as for softmmu.
155
+
* The mmu_idx argument is ignored.
156
+
*/
157
+
158
+
static inline uint32_t cpu_ldub_mmuidx_ra(CPUArchState *env, abi_ptr addr,
159
+
int mmu_idx, uintptr_t ra)
160
+
{
161
+
return cpu_ldub_data_ra(env, addr, ra);
162
+
}
163
+
164
+
static inline uint32_t cpu_lduw_mmuidx_ra(CPUArchState *env, abi_ptr addr,
165
+
int mmu_idx, uintptr_t ra)
166
+
{
167
+
return cpu_lduw_data_ra(env, addr, ra);
168
+
}
169
+
170
+
static inline uint32_t cpu_ldl_mmuidx_ra(CPUArchState *env, abi_ptr addr,
171
+
int mmu_idx, uintptr_t ra)
172
+
{
173
+
return cpu_ldl_data_ra(env, addr, ra);
174
+
}
175
+
176
+
static inline uint64_t cpu_ldq_mmuidx_ra(CPUArchState *env, abi_ptr addr,
177
+
int mmu_idx, uintptr_t ra)
178
+
{
179
+
return cpu_ldq_data_ra(env, addr, ra);
180
+
}
181
+
182
+
static inline int cpu_ldsb_mmuidx_ra(CPUArchState *env, abi_ptr addr,
183
+
int mmu_idx, uintptr_t ra)
184
+
{
185
+
return cpu_ldsb_data_ra(env, addr, ra);
186
+
}
187
+
188
+
static inline int cpu_ldsw_mmuidx_ra(CPUArchState *env, abi_ptr addr,
189
+
int mmu_idx, uintptr_t ra)
190
+
{
191
+
return cpu_ldsw_data_ra(env, addr, ra);
192
+
}
193
+
194
+
static inline void cpu_stb_mmuidx_ra(CPUArchState *env, abi_ptr addr,
195
+
uint32_t val, int mmu_idx, uintptr_t ra)
196
+
{
197
+
cpu_stb_data_ra(env, addr, val, ra);
198
+
}
199
+
200
+
static inline void cpu_stw_mmuidx_ra(CPUArchState *env, abi_ptr addr,
201
+
uint32_t val, int mmu_idx, uintptr_t ra)
202
+
{
203
+
cpu_stw_data_ra(env, addr, val, ra);
204
+
}
205
+
206
+
static inline void cpu_stl_mmuidx_ra(CPUArchState *env, abi_ptr addr,
207
+
uint32_t val, int mmu_idx, uintptr_t ra)
208
+
{
209
+
cpu_stl_data_ra(env, addr, val, ra);
210
+
}
211
+
212
+
static inline void cpu_stq_mmuidx_ra(CPUArchState *env, abi_ptr addr,
213
+
uint64_t val, int mmu_idx, uintptr_t ra)
214
+
{
215
+
cpu_stq_data_ra(env, addr, val, ra);
216
+
}
147
217
148
218
#else
149
219