From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:58151) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YxEab-00010j-FV for qemu-devel@nongnu.org; Tue, 26 May 2015 09:08:17 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YxEaX-0001Xz-JQ for qemu-devel@nongnu.org; Tue, 26 May 2015 09:08:13 -0400 Received: from mail-wg0-f42.google.com ([74.125.82.42]:34592) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YxEaX-0001Xv-EA for qemu-devel@nongnu.org; Tue, 26 May 2015 09:08:09 -0400 Received: by wghq2 with SMTP id q2so96663543wgh.1 for ; Tue, 26 May 2015 06:08:08 -0700 (PDT) Message-ID: <5564702F.2030308@linaro.org> Date: Tue, 26 May 2015 15:07:59 +0200 From: Eric Auger MIME-Version: 1.0 References: <1432464666-4825-1-git-send-email-christoffer.dall@linaro.org> <1432464666-4825-5-git-send-email-christoffer.dall@linaro.org> <55646D0F.9040801@linaro.org> In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH v3 4/4] target-arm: Add the GICv2m to the virt board List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Peter Maydell Cc: QEMU Developers , Christoffer Dall , "kvmarm@lists.cs.columbia.edu" On 05/26/2015 02:55 PM, Peter Maydell wrote: > On 26 May 2015 at 13:54, Eric Auger wrote: >> Reviewed-by: Eric Auger >> >> The only question I have is related to mid-term virt strategy about >> GICv3 integration. Are we going to reuse that memory map for the machine >> instantiating the GICv3? If yes, shouldn't we put the GICv2M somewhere >> else to leave space for GICv3 redistributors, assuming we reuse the >> shared distributor region. I understood the memory map is difficult to >> change once applied once. > > I wouldn't expect that you'd have a GICv2M at all in a > system with a GICv3 in it, would you? no indeed. but we currently use a single static a15memmap memory map in virt. This one is currently planned to be reused for machines instantiating GICv3 so we start seeing things like VIRT_GIC_CPU = VIRT_GIC_REDIST. I fear this is going to become messy. What is your guidance, should we introduce new memory maps for GICv3 enabled machine or should we move to a single dynamic memory map? Best Regards Eric > > -- PMM >