[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Paolo Bonzini
Subject: Re: [Qemu-devel] [mttcg] cputlb: Use async tlb_flush_by_mmuidx
Date: Mon, 7 Mar 2016 22:18:09 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0

On 04/03/2016 15:28, alvise rigo wrote:
> 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 think in both cases the function to use is cpu_loop_exit_restore.  It
will restart execution of the current instruction so it should be fine
as long as you don't call it unconditionally.

If you're not calling it directly from the helper, you need to save
GETPC() in the helper and propagate it down to the call site.  Then the
call site can use it as the last argument.  For an example see
helper_ljmp_protected's call to switch_tss_ra in target-i386/seg_helper.c.

> I wanted then to apply the same "halted state" to the LoadLink helper,
> since also this one might cause some flush requests.

Interesting, where is this documented in the ARM ARM?

> 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?

Perhaps cpu_loop_exit_restore()?


reply via email to

[Prev in Thread] Current Thread [Next in Thread]