On Mon, Feb 29, 2016 at 2:55 PM, Peter Maydell <peter.mayd...@linaro.org> wrote: > On 29 February 2016 at 13:50, Paolo Bonzini <pbonz...@redhat.com> wrote: >> >> >> On 29/02/2016 14:21, Peter Maydell wrote: >>> On 29 February 2016 at 13:16, Alvise Rigo <a.r...@virtualopensystems.com> >>> wrote: >>>> > As in the case of tlb_flush(), also tlb_flush_by_mmuidx has to query the >>>> > TLB flush if it targets another VCPU. To accomplish this, a new async >>>> > work has been added, together with a new TLBFlushByMMUIdxParams. A >>>> > bitmap is used to track the MMU indexes to flush. >>>> > >>>> > This patch applies to the multi_tcg_v8 branch. >>> What's the API for a target CPU emulation to say "and now I must >>> wait for the TLB op to finish" before completing this guest >>> instruction? >> >> My proposal has been for a while for DMB to put the CPU in a halted >> state (remote TLB callbacks then can decrement a counter and signal >> cpu_halt_cond when it's zero), but no one has implemented this. > > 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? Thank you, alvise > > thanks > -- PMM