On 10 August 2015 at 16:54, Paolo Bonzini <pbonz...@redhat.com> wrote: > On 10/08/2015 17:27, fred.kon...@greensocs.com wrote: >> From: KONRAD Frederic <fred.kon...@greensocs.com> >> >> Some architectures allow to flush the tlb of other VCPUs. This is not a >> problem >> when we have only one thread for all VCPUs but it definitely needs to be an >> asynchronous work when we are in true multithreaded work. >> >> TODO: Some test case, I fear some bad results in case a VCPUs execute a >> barrier >> or something like that. >> >> Signed-off-by: KONRAD Frederic <fred.kon...@greensocs.com> >> --- >> cputlb.c | 76 >> +++++++++++++++++++++++++++++++++++++++++++++++++ >> include/exec/exec-all.h | 2 ++ >> 2 files changed, 78 insertions(+) > > I still believe this should be a target-specific change. This would > also make it easier to do the remote TLB flush synchronously, as is the > case on ARM (if I understand correctly).
ARM TLB flushes have to complete by the next barrier instruction (or equivalent thing); so they're asynchronous but with a guest-controlled synchronization point. Also, compare the series I posted recently for adding missing TLB operations: https://lists.gnu.org/archive/html/qemu-devel/2015-08/msg00945.html which adds support for flush-specific-mmuidx operations, which would increase the number of primitives you're trying to support here. That might argue for making this target-specific. thanks -- PMM
