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
