| Message ID | 20240724194708.1843704-1-pierrick.bouvier@linaro.org (mailing list archive) |
|---|---|
| Headers | show |
| Series | plugins: access values during a memory read/write | expand |
Pierrick Bouvier <pierrick.bouvier@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.
On 9/5/24 08:21, Alex Bennée wrote: > Pierrick Bouvier <pierrick.bouvier@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. 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.
Pierrick Bouvier <pierrick.bouvier@linaro.org> writes: > On 9/5/24 08:21, Alex Bennée wrote: >> Pierrick Bouvier <pierrick.bouvier@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? > 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?
On 9/9/24 03:00, Alex Bennée wrote: > Pierrick Bouvier <pierrick.bouvier@linaro.org> writes: > >> On 9/5/24 08:21, Alex Bennée wrote: >>> Pierrick Bouvier <pierrick.bouvier@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 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. 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.
Pierrick Bouvier <pierrick.bouvier@linaro.org> writes: > On 9/9/24 03:00, Alex Bennée wrote: >> Pierrick Bouvier <pierrick.bouvier@linaro.org> writes: >> >>> On 9/5/24 08:21, Alex Bennée wrote: >>>> Pierrick Bouvier <pierrick.bouvier@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.
On 9/9/24 13:21, Alex Bennée wrote: > Pierrick Bouvier <pierrick.bouvier@linaro.org> writes: > >> On 9/9/24 03:00, Alex Bennée wrote: >>> Pierrick Bouvier <pierrick.bouvier@linaro.org> writes: >>> >>>> On 9/5/24 08:21, Alex Bennée wrote: >>>>> Pierrick Bouvier <pierrick.bouvier@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!