On 12/8/20 7:48 PM, Robert Henry wrote:
Richard:
I posted this item to qemu-discuss yesterday, but cc:ed you to the wrong
address.
...
It looks like the emulation of AARCH64 SVE and SVE2 instructions is not
calling the part of the plugin interface that is supposed to be called when
there is a memory operation, viz the function registered by a call to
qemu_plugin_register_vcpu_mem_cb
Nope, nor for most any other out-of-line memory operation performed by any
other qemu target. Starting with arm's own dc zva.
The plugin interface needs extension for this. How should I signal that 256
consecutive byte loads have occurred? How should I signal that the controlling
predicate was not all true, so only 250 of those 256 were actually active? How
should I signal 59 non-consecutive (gather) loads have occurred?
If the answer is simply that you want 256 or 250 or 59 plugin callbacks
respectively, then we might be able to force the memory operations into the
slow path, and hook the operation there. As if it were an i/o operation.
There are other changes to the slow path that need changing, because at present
I do not have enough bits to represent 256-bit alignment for (specifically)
arm32 neon "vld4 {d0-d3},[r0:256]". So perhaps I can work in the plugin thing
at the same time.
Thoughts?
r~