From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:41959) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SWNDQ-0001X6-V6 for qemu-devel@nongnu.org; Mon, 21 May 2012 03:39:42 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SWNDL-00045I-VA for qemu-devel@nongnu.org; Mon, 21 May 2012 03:39:40 -0400 Received: from gate.crashing.org ([63.228.1.57]:55982) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SWNDL-00044m-M6 for qemu-devel@nongnu.org; Mon, 21 May 2012 03:39:35 -0400 Message-ID: <1337585966.2779.8.camel@pasglop> From: Benjamin Herrenschmidt Date: Mon, 21 May 2012 17:39:26 +1000 In-Reply-To: References: <1337054780.6727.60.camel@pasglop> <1337565668.2458.14.camel@pasglop> <31BB839A-D102-497A-AA5B-39E41A039F14@suse.de> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit Mime-Version: 1.0 Subject: Re: [Qemu-devel] ppc: CPU reset must flush translation buffer List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Peter Maydell Cc: Alexander Graf , Andreas =?ISO-8859-1?Q?F=E4rber?= , "qemu-devel@nongnu.org" On Mon, 2012-05-21 at 08:15 +0100, Peter Maydell wrote: > The conclusion we came to is that you only need to tb_flush > in your CPU's reset function if you have some CPU state which > you handle by baking it into translated code and doing a tb_flush > when the state changes. This is relatively rare, most CPU > frontends only use the other options: > (a) CPU state is constant for life of simulation > (b) CPU state not baked into code > (c) CPU state encoded in tb_flags. > > In particular, target-ppc doesn't have any uses of tb_flush > at the moment, so either this fix is insufficient (and you need > to also use tb_flush at the point where the relevant state is > changed by whatever helper function) or it's the wrong fix. > > If the issue is ROM reloading then the loading code needs to > be fixed (compare the way that the memory region API correctly > handles bits of physical memory being mapped/unmapped/remapped > without the caller needing to do a tb_reset). Hrm, the state shouldn't change in a drastic way.... we can reproduce from SLOF which is in real mode and the reset happens in real mode... it looks like a flush of the exception vectors problem to me. So that would mean that the ROM reload isn't flushing properly (well, possibly, need to investigate more). From what I can tell the reload is done implicitely by generic qemu code creating rom objects when I call load_image_targphys. So if something is missing here it's from the generic code, I will dig a bit more later, gotta take care of sick kids... Cheers, Ben.