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
