On Tue, Sep 8, 2026 at 11:54 AM Peter Maydell <[email protected]> wrote: > On Tue, 8 Sept 2026 at 10:29, Paolo Bonzini <[email protected]> wrote: > > On Tue, Sep 8, 2026 at 10:40 AM Peter Maydell <[email protected]> > > wrote: > > > I bet also that most targets don't expect it. Picking one at > > > random, the sparc has_work function calls e.g. cpu_interrupts_enabled() > > > which does not look like a function that is expecting to be called > > > without the BQL. > > > > Why? It only accesses fields for the local CPU. The problem is > > interprocedural communication, and only if it does not use > > cpu_interrupt(). > > Mmm, I guess this is OK: actual TCG code execution also accesses > local CPU fields with the BQL not held, and if we're definitely > always on the local vcpu thread when we call has_work then > this is more or less the same thing. Doing anything more complicated > than "we hold a lock" for thread-safety makes me nervous, is all :-)
Rightly so, but locks aren't always easy either. They can introduce more problems or more widespread changes and "we're always on the thread" in the end is mutual exclusion just like locks, only spatial instead of temporal. It's the ultimate thread-safety solution and, as you noticed, it's the core of MTTCG's BQL-less execution. And abstractions such as cpu_interrupt are needed even if they use locks internally. The problem is that C doesn't provide any tool to tell you that your accesses are not local, or that your accesses are not holding the lock, neither at compile time nor at run time (the BqlRefCell in the Rust bindings are an example of run time checks). Paolo Paolo
