From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:35292) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WFhLJ-0003Jf-AS for qemu-devel@nongnu.org; Tue, 18 Feb 2014 04:52:02 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WFhLA-0002b2-DU for qemu-devel@nongnu.org; Tue, 18 Feb 2014 04:51:57 -0500 Received: from mail-lb0-f179.google.com ([209.85.217.179]:38388) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WFhLA-0002an-72 for qemu-devel@nongnu.org; Tue, 18 Feb 2014 04:51:48 -0500 Received: by mail-lb0-f179.google.com with SMTP id l4so12203957lbv.10 for ; Tue, 18 Feb 2014 01:51:47 -0800 (PST) MIME-Version: 1.0 In-Reply-To: <5302B40F.5090009@suse.de> References: <53022228.3000201@galauner.de> <5302B40F.5090009@suse.de> From: Peter Maydell Date: Tue, 18 Feb 2014 09:51:26 +0000 Message-ID: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] Cortex-M3: reading NVIC registers causes segfaults List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: =?UTF-8?Q?Andreas_F=C3=A4rber?= Cc: "Edgar E. Iglesias" , Andreas Galauner , QEMU Developers , Paolo Bonzini On 18 February 2014 01:14, Andreas F=C3=A4rber wrote: > While first_cpu may help Andreas in his local copy for STM32, that > assumption is not okay in general. The Vybrid VF6 has both a GIC and an > NVIC, so our NVIC code should not make assumptions which CPU it can > access. Do you mean it has an M core CPU with an NVIC plus some other A-class CPU with a GIC. Certainly in a system with heterogenous CPUs this change won't work, but we don't support that at all currently and there's a lot of work between here and there. > I assume we would shield both using CPU address spaces The GIC needs to know which CPU it's being accessed by. I guess in theory you could have it export N distributor memory regions which were identical apart from making "I assume I'm being accessed by CPU X" assumptions, but that seems like a bit of a kludge. Ideally we should have some way for the target of a memory transaction to get at information about the source (ie all the out of band info that hardware sends like master ID, privilege level, secure vs nonsecure, etc). > but I > wonder if either of you two has already thought about how those will > interact for gdbstub? I'd need to look at the protocol to figure out if gdbstub does memory accesses in the context of a particular thread (CPU for us) or not. If not, that could be awkward. thanks -- PMM