From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:52527) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZOpVb-0004vr-Kn for qemu-devel@nongnu.org; Mon, 10 Aug 2015 12:01:08 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZOpVV-0000MX-Oe for qemu-devel@nongnu.org; Mon, 10 Aug 2015 12:01:07 -0400 Received: from mail-vk0-f52.google.com ([209.85.213.52]:35601) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZOpVV-0000M8-F3 for qemu-devel@nongnu.org; Mon, 10 Aug 2015 12:01:01 -0400 Received: by vkfi73 with SMTP id i73so18486870vkf.2 for ; Mon, 10 Aug 2015 09:01:01 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: <55C8C923.5050208@redhat.com> References: <1439220437-23957-1-git-send-email-fred.konrad@greensocs.com> <1439220437-23957-15-git-send-email-fred.konrad@greensocs.com> <55C8C923.5050208@redhat.com> From: Peter Maydell Date: Mon, 10 Aug 2015 17:00:41 +0100 Message-ID: Content-Type: text/plain; charset=UTF-8 Subject: Re: [Qemu-devel] [RFC PATCH V7 14/19] cpu: introduce tlb_flush*_all. List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Paolo Bonzini Cc: mttcg@greensocs.com, Mark Burton , Alvise Rigo , QEMU Developers , Guillaume Delbergue , =?UTF-8?B?QWxleCBCZW5uw6ll?= , =?UTF-8?B?S09OUkFEIEZyw6lkw6lyaWM=?= On 10 August 2015 at 16:54, Paolo Bonzini wrote: > On 10/08/2015 17:27, fred.konrad@greensocs.com wrote: >> From: KONRAD Frederic >> >> 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 >> --- >> 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