From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:41612) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YLSsT-00013M-Sb for qemu-devel@nongnu.org; Wed, 11 Feb 2015 03:42:34 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YLSsO-0006yn-HL for qemu-devel@nongnu.org; Wed, 11 Feb 2015 03:42:33 -0500 Received: from greensocs.com ([193.104.36.180]:59028) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YLSsO-0006yZ-7A for qemu-devel@nongnu.org; Wed, 11 Feb 2015 03:42:28 -0500 Message-ID: <54DB15F0.1060004@greensocs.com> Date: Wed, 11 Feb 2015 09:42:24 +0100 From: Frederic Konrad MIME-Version: 1.0 References: <54D885A0.3080609@greensocs.com> <87pp9hrukd.fsf@linaro.org> In-Reply-To: <87pp9hrukd.fsf@linaro.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] CPU TLB flush with multithread TCG. List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: =?UTF-8?B?QWxleCBCZW5uw6ll?= Cc: mttcg@listserver.greensocs.com, Peter Maydell , Jan Kiszka , qemu-devel , Alexander Graf , Paolo Bonzini On 11/02/2015 04:33, Alex Benn=C3=A9e wrote: > Frederic Konrad writes: > >> Hi everybody, >> >> In multithread tlb_flush is broken as CPUA can flush an other CPUB and >> CPUB can be >> executing code, and fixing this can be quite hard: >> * We need to exit the CPU which is flushed. >> * Makes sure the CPU is stopped. >> * Then we can flush tlb. >> The big issues are: >> * Two threads can be doing a flush at the same time. >> * Something can restart the CPU during the flush. >> >> A better idea I think is that instead of flushing tlb we can put a fla= g >> in CPUState such >> as flush_request and ask the cpu to exit. >> Then later once the CPU is exited we can flush tlbs if flush_request i= s set. >> It will ensure that the CPU won't execute code as it's associated thre= ad >> will be >> flushing. >> >> Can this work? > Does this imply deferring the work? Surely if we don't flush when > instructed things could break down very quickly? > Yes this imply deferring the work. It might be an issue as we can't exit=20 the CPU directly, they will finish their execution before flushing.. But maybe it's only a problem if the CPU flushes himself? eg: if CPUB is executing instructions and CPUA wants to flush it: does=20 that makes a difference if the flush happen before or after the block of instruction=20 executed by CPUB? Thanks, Fred > >> Thanks, >> Fred