Re: [Qemu-devel] [mttcg] cputlb: Use async tlb_flush_by_mmuidx

["Alex Bennée" <alex.bennee@linaro.org>]

alvise rigo <a.rigo@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.rigo@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 <pbonzini@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