From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:44749) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ff396-0003EC-TF for qemu-devel@nongnu.org; Mon, 16 Jul 2018 09:02:33 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ff391-0003QS-4V for qemu-devel@nongnu.org; Mon, 16 Jul 2018 09:02:32 -0400 Received: from mail-oi0-x242.google.com ([2607:f8b0:4003:c06::242]:34631) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1ff390-0003Q3-U0 for qemu-devel@nongnu.org; Mon, 16 Jul 2018 09:02:27 -0400 Received: by mail-oi0-x242.google.com with SMTP id 13-v6so74589141ois.1 for ; Mon, 16 Jul 2018 06:02:26 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: References: <20180710160013.26559-1-peter.maydell@linaro.org> From: Peter Maydell Date: Mon, 16 Jul 2018 14:02:05 +0100 Message-ID: Content-Type: text/plain; charset="UTF-8" Subject: Re: [Qemu-devel] [PATCH 0/6] accel/tcg: Support execution from MMIO and small MMU regions List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: KONRAD Frederic Cc: qemu-arm , QEMU Developers , "patches@linaro.org" , Richard Henderson , "Emilio G . Cota" , Paolo Bonzini , =?UTF-8?Q?C=C3=A9dric_Le_Goater?= , "Edgar E. Iglesias" On 16 July 2018 at 13:30, KONRAD Frederic wrote: > Hi Peter, > > Nice! Thanks for that. > > A little question though.. What will happen in the case where the > CPU start executing code at random place because of eg: a badly > configured kernel? > > Seeing the patch 5 I guess it will really execute stuff.. So > maybe this is less user-friendly? Yes, it's true that we will now happily execute from anything (device, unassigned memory, etc), and do what the real hardware would do in that situation (random unhelpful things, infinite loop of taking exceptions). That's a bit unavoidable though I think, and there are already lots of cases where QEMU will just sit there with a black screen because the user has loaded in a bad guest image that goes off into the weeds without printing anything to a UART. It's possible we could devise a user-friendliness option that tried to pick up symptoms of guests being stuck (eg tracking whether we're continuously taking exceptions) but that gets into heuristics a bit. thanks -- PMM