From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:37067) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RjqkK-00083n-Gy for qemu-devel@nongnu.org; Sun, 08 Jan 2012 06:17:06 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RjqkJ-0005og-Bv for qemu-devel@nongnu.org; Sun, 08 Jan 2012 06:17:04 -0500 Received: from mx1.redhat.com ([209.132.183.28]:40674) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RjqkJ-0005oa-0P for qemu-devel@nongnu.org; Sun, 08 Jan 2012 06:17:03 -0500 Message-ID: <4F097B29.7040608@redhat.com> Date: Sun, 08 Jan 2012 13:16:57 +0200 From: Avi Kivity 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> In-Reply-To: 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: Peter Maydell Cc: =?UTF-8?B?QmVub8OudCBDYW5ldA==?= , =?UTF-8?B?QW5kcmVhcyBGw6RyYmVy?= , patches@linaro.org, qemu-devel@nongnu.org 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. > Correct, and the memory core will flush the tlb, so all is well. --=20 error compiling committee.c: too many arguments to function