alvise rigo <a.r...@virtualopensystems.com> writes: > A small update on this. I have a working implementation of the "halted > state" mechanism for waiting all the pending flushes to be completed. > However, the way I'm going back to the cpus.c loop (the while(1) in > qemu_tcg_cpu_thread_fn) is a bit convoluted. In the case of the TLB ops > that always end the TB, a simple cpu_exit() allows me to go back to the > main loop. I think in this case we can also use the cpu_loop_exit(), though > making the code a bit more complicated since the PC would require some > adjustments. > > I wanted then to apply the same "halted state" to the LoadLink helper, > since also this one might cause some flush requests. In this case, we can > not just call cpu_loop_exit() in that the guest code would miss the > returned value. Forcing the LDREX instruction to also end the TB through an > empty 'is_jmp' condition did the trick allowing once again to use > cpu_exit(). Is there another better solution?
Have you looked at Emilio's tree where he replaced the async_safe_work mechanism with a mechanism to do the work in the vCPU run loop but halt all other vCPUs first? > > Thank you, > alvise > > On Mon, Feb 29, 2016 at 3:18 PM, alvise rigo <a.r...@virtualopensystems.com> > wrote: > >> I see the risk. I will come back with something and let you know. >> >> Thank you, >> alvise >> >> On Mon, Feb 29, 2016 at 3:06 PM, Paolo Bonzini <pbonz...@redhat.com> >> wrote: >> > >> > >> > On 29/02/2016 15:02, alvise rigo wrote: >> >> > Yeah, that's the other approach -- really split the things that can >> >> > be async and do real "wait for completion" at points which must >> >> > synchronize. (Needs a little care since DMB is not the only such >> point.) >> >> > An initial implementation that does an immediate wait-for-completion >> >> > is probably simpler to review though, and add the real asynchrony >> >> > later. And either way you need an API for the target to wait for >> >> > completion. >> >> OK, so basically being sure that the target CPU performs the flush >> >> before executing the next TB is not enough. We need a sort of feedback >> >> that the flush has been done before emulating the next guest >> >> instruction. Did I get it right? >> > >> > That risks getting deadlocks if CPU A asks B to flush the TLB and vice >> > versa. Using a halted state means that the VCPU thread goes through the >> > cpus.c loop and can for example service other CPUs' TLB flush requests. >> > >> > Paolo >> -- Alex Bennée
