Pierrick Bouvier <pierrick.bouv...@linaro.org> writes: > On 1/12/24 21:20, Alex Bennée wrote: >> Pierrick Bouvier <pierrick.bouv...@linaro.org> writes: >> >>> On 1/11/24 19:57, Philippe Mathieu-Daudé wrote: >>>> Hi Pierrick, >>>> On 11/1/24 15:23, Pierrick Bouvier wrote: >>>>> For now, it simply performs instruction, bb and mem count, and ensure >>>>> that inline vs callback versions have the same result. Later, we'll >>>>> extend it when new inline operations are added. >>>>> >>>>> Use existing plugins to test everything works is a bit cumbersome, as >>>>> different events are treated in different plugins. Thus, this new one. >>>>> <snip> >>>>> +#define MAX_CPUS 8 >>>> Where does this value come from? >>>> >>> >>> The plugin tests/plugin/insn.c had this constant, so I picked it up >>> from here. >>> >>>> Should the pluggin API provide a helper to ask TCG how many >>>> vCPUs are created? >>> >>> In user mode, we can't know how many simultaneous threads (and thus >>> vcpu) will be triggered by advance. I'm not sure if additional cpus >>> can be added in system mode. >>> >>> One problem though, is that when you register an inline op with a >>> dynamic array, when you resize it (when detecting a new vcpu), you >>> can't change it afterwards. So, you need a storage statically sized >>> somewhere. >>> >>> Your question is good, and maybe we should define a MAX constant that >>> plugins should rely on, instead of a random amount. >> For user-mode it can be infinite. The existing plugins do this by >> ensuring vcpu_index % max_vcpu. Perhaps we just ensure that for the >> scoreboard as well? Of course that does introduce a trap for those using >> user-mode... >> > > The problem with vcpu-index % max_vcpu is that it reintroduces race > condition, though it's probably less frequent than on a single > variable. IMHO, yes it solves memory error, but does not solve the > initial problem itself. > > The simplest solution would be to have a size "big enough" for most > cases, and abort when it's reached.
Well that is simple enough for system emulation as max_vcpus is a bounded number. > Another solution, much more complicated, but correct, would be to move > memory management of plugin scoreboard to plugin runtime, and add a > level of indirection to access it. That certainly gives us the most control and safety. We can then ensure we'll never to writing past the bounds of the buffer. The plugin would have to use an access function to get the pointer to read at the time it cared and of course inline checks should be pretty simple. > Every time a new vcpu is added, we > can grow dynamically. This way, the array can grow, and ultimately, > plugin can poke its content/size. I'm not sure this complexity is what > we want though. It doesn't seem too bad. We have a start/end_exclusive is *-user do_fork where we could update pointers. If we are smart about growing the size of the arrays we could avoid too much re-translation. Do we want a limit of one scoreboard per thread? Can we store structures in there? -- Alex Bennée Virtualisation Tech Lead @ Linaro
