From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from zen.linaro.local ([81.128.185.34]) by smtp.gmail.com with ESMTPSA id l19sm7893833wmg.5.2016.10.28.02.17.09 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 28 Oct 2016 02:17:09 -0700 (PDT) Received: from zen (localhost [127.0.0.1]) by zen.linaro.local (Postfix) with ESMTPS id 068EE3E01C6; Fri, 28 Oct 2016 10:17:09 +0100 (BST) References: <20161027151030.20863-1-alex.bennee@linaro.org> <20161027151030.20863-31-alex.bennee@linaro.org> <87bmy498bg.fsf@linaro.org> User-agent: mu4e 0.9.17; emacs 25.1.50.12 From: Alex =?utf-8?Q?Benn=C3=A9e?= To: Peter Maydell Cc: Richard Henderson , Paolo Bonzini , QEMU Developers , MTTCG Devel , KONRAD =?utf-8?B?RnLDqWTDqXJpYw==?= , Alvise Rigo , "Emilio G. Cota" , Pranith Kumar , Nikunj A Dadhania , Mark Burton , Jan Kiszka , Fedorov Sergey , Claudio Fontana , "open list\:ARM" Subject: Re: [PATCH v5 30/33] target-arm/cpu: don't reset TLB structures, use cputlb to do it In-reply-to: Date: Fri, 28 Oct 2016 10:17:08 +0100 Message-ID: <87a8do96jv.fsf@linaro.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-TUID: UjjIqimnIyUl Peter Maydell writes: > On 28 October 2016 at 09:38, Alex Bennée wrote: >> >> Richard Henderson writes: >>> And don't we (or if not, shouldn't we) >>> handle the tlb_flush generically for reset? >> >> Probably. tlb_flush seems to be one of those things liberally sprinkled >> in the arch code for all sorts of things but certainly cpu_reset is one >> we could make the call from generic code. > > I think the theory I formed last time I looked at it is that > if your CPU has no state which would require you to flush the > TLB when it changes, then there's no need to flush the TLB > on reset -- any entries still in the TLB from before reset are > still valid after reset. For ARM a CPU reset will reset state > like the ASID and the MMU-enabled bit which require a TLB flush > on change, so we have to call tlb_flush here. > > You could argue that the set of CPUs which don't require a > tlb flush on reset are not worth trying to optimise for > like this and we should just do it generically. Well it can't harm anyone. It would just mean all CPUs whatever their semantics would have to re-fill the TLBs after a reset. I guess that might be a concern for reset latency under TCG but I doubt anyone would notice. -- Alex Bennée From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:46136) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1c03Hm-00034R-IR for qemu-devel@nongnu.org; Fri, 28 Oct 2016 05:17:15 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1c03Hj-0005D3-CW for qemu-devel@nongnu.org; Fri, 28 Oct 2016 05:17:14 -0400 Received: from mail-wm0-x22f.google.com ([2a00:1450:400c:c09::22f]:38690) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1c03Hj-0005BP-4o for qemu-devel@nongnu.org; Fri, 28 Oct 2016 05:17:11 -0400 Received: by mail-wm0-x22f.google.com with SMTP id n67so100148234wme.1 for ; Fri, 28 Oct 2016 02:17:11 -0700 (PDT) References: <20161027151030.20863-1-alex.bennee@linaro.org> <20161027151030.20863-31-alex.bennee@linaro.org> <87bmy498bg.fsf@linaro.org> From: Alex =?utf-8?Q?Benn=C3=A9e?= In-reply-to: Date: Fri, 28 Oct 2016 10:17:08 +0100 Message-ID: <87a8do96jv.fsf@linaro.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Subject: Re: [Qemu-devel] [PATCH v5 30/33] target-arm/cpu: don't reset TLB structures, use cputlb to do it List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Peter Maydell Cc: Richard Henderson , Paolo Bonzini , QEMU Developers , MTTCG Devel , KONRAD =?utf-8?B?RnLDqWTDqXJpYw==?= , Alvise Rigo , "Emilio G. Cota" , Pranith Kumar , Nikunj A Dadhania , Mark Burton , Jan Kiszka , Fedorov Sergey , Claudio Fontana , "open list:ARM" Peter Maydell writes: > On 28 October 2016 at 09:38, Alex Bennée wrote: >> >> Richard Henderson writes: >>> And don't we (or if not, shouldn't we) >>> handle the tlb_flush generically for reset? >> >> Probably. tlb_flush seems to be one of those things liberally sprinkled >> in the arch code for all sorts of things but certainly cpu_reset is one >> we could make the call from generic code. > > I think the theory I formed last time I looked at it is that > if your CPU has no state which would require you to flush the > TLB when it changes, then there's no need to flush the TLB > on reset -- any entries still in the TLB from before reset are > still valid after reset. For ARM a CPU reset will reset state > like the ASID and the MMU-enabled bit which require a TLB flush > on change, so we have to call tlb_flush here. > > You could argue that the set of CPUs which don't require a > tlb flush on reset are not worth trying to optimise for > like this and we should just do it generically. Well it can't harm anyone. It would just mean all CPUs whatever their semantics would have to re-fill the TLBs after a reset. I guess that might be a concern for reset latency under TCG but I doubt anyone would notice. -- Alex Bennée