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. > 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. -- Alex Bennée Virtualisation Tech Lead @ Linaro
