On 9/9/24 13:21, Alex Bennée wrote:
Pierrick Bouvier <pierrick.bouv...@linaro.org> writes:

On 9/9/24 03:00, Alex Bennée wrote:
Pierrick Bouvier <pierrick.bouv...@linaro.org> writes:

On 9/5/24 08:21, Alex Bennée wrote:
Pierrick Bouvier <pierrick.bouv...@linaro.org> writes:

This series allows plugins to know which value is read/written during a memory
access.

For every memory access, we know copy this value before calling mem callbacks,
and those can query it using new API function:
- qemu_plugin_mem_get_value
Queued to patches 1-5 to plugins/next, thanks.
You can send the re-spun version of 6 once the review comments have
been
done.


Thanks Alex,

right now, my try to make check-tcg are blocked with the cross
containers who don't compile, so I'll wait for this to be resolved.
Which ones?

docker-image-debian-mips64el-cross
docker-image-debian-mipsel-cross
(about broken packages).

I have fixes for mipsel at least when I post my series.


I saw something mentioning this recently on the mailing list, so not
sure what would be our solution to this (ignoring?)


I still wonder if having a simple aarch64/x64 test is not enough, and
covering 99.9% of the bug we could introduce in the future on this.
Have you measured the code coverage of the test?


Nope, but all the code changed is tcg-generic, so testing this on all
arch does not bring benefit in terms of coverage.

Would that it were so simple. Quite often which bits of the generic TCG
code get exercised depends on the guest architecture using it. I'm not
saying we have to go over and above to enable fiddly architectures but we
should at least understand if the reason they fail is down to them or
core code.

I understand your point, and will try to make this work on all arch.


So by focusing on the "all arch" aspect, we just test tcg
implementation itself, instead of the plugins part.

The problems we identified so far is compilation flags specific per
arch, and specific flags to emit words instruction. It does not seem
related to what we really want to test here.

I'm also investigating why arm-softmmu seems to be seeing more accesses
than it should have from the test.


Good!

Reply via email to