From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:44434) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RjqoG-0000aw-Hh for qemu-devel@nongnu.org; Sun, 08 Jan 2012 06:21:09 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RjqoF-0006Jc-88 for qemu-devel@nongnu.org; Sun, 08 Jan 2012 06:21:08 -0500 Received: from cantor2.suse.de ([195.135.220.15]:43975 helo=mx2.suse.de) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RjqoE-0006JY-Pd for qemu-devel@nongnu.org; Sun, 08 Jan 2012 06:21:07 -0500 Message-ID: <4F097BC6.50607@suse.de> Date: Sun, 08 Jan 2012 12:19:34 +0100 From: =?UTF-8?B?QW5kcmVhcyBGw6RyYmVy?= MIME-Version: 1.0 References: <1325876308-28097-1-git-send-email-peter.maydell@linaro.org> <1325876308-28097-3-git-send-email-peter.maydell@linaro.org> <4F07CCD2.4040003@suse.de> <4F097B29.7040608@redhat.com> In-Reply-To: <4F097B29.7040608@redhat.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [PATCH v4 2/2] hw/integratorcp: Simplify flash remap code List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Avi Kivity Cc: Peter Maydell , =?UTF-8?B?QmVub8OudCBDYW5ldA==?= , qemu-devel@nongnu.org, patches@linaro.org Am 08.01.2012 12:16, schrieb Avi Kivity: > On 01/07/2012 06:09 PM, Peter Maydell wrote: >> On 7 January 2012 04:40, Andreas F=C3=A4rber wrote: >>> I noticed you're dropping a comment about tlb_flush(). Is that becaus= e >>> it was dead code, or does the Memory API take care of it for us? >>> (I assume the former because memory_region_set_enabled() does not tak= e a >>> CPUState* to operate on.) >> >> Arranging for a tlb_flush if needed has to be the Memory API's >> problem, because everything that uses the memory API to rearrange >> the view of the address space has exactly the same requirement that >> anything else in QEMU has to be told it may need to redo any caching >> data structure it has set up. In particular, this doesn't apply just >> for a single CPUState* -- in a multicore system every CPU has to be >> made aware that the world has changed, not just the one which >> happened to do the store to the "remap the flash" register. >> Also the memory API is the only thing that knows whether the region >> was already enabled (ie this is a no-op), whether some other region >> is overlapping so in fact it makes no difference whether we enable >> or disable this one, etc etc). >> >> So basically I dropped that line because it was a bit of commented >> out code with a ??? marker appended, and the device layer is the >> wrong place to be trying to solve the issue it was gesturing at. >> >=20 > Correct, and the memory core will flush the tlb, so all is well. Hm, I had grep'ed for tlb_flush in memory.* without a hit... I would've assumed to find tlb_flush_all() somewhere. Andreas --=20 SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 N=C3=BCrnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imend=C3=B6rffer; HRB 16746 AG N=C3=BC= rnberg