From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:36818) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1V6K2s-00051s-9u for qemu-devel@nongnu.org; Mon, 05 Aug 2013 08:37:59 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1V6K2m-00062E-Vc for qemu-devel@nongnu.org; Mon, 05 Aug 2013 08:37:54 -0400 Received: from mail-ve0-f174.google.com ([209.85.128.174]:33053) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1V6K2m-000628-SB for qemu-devel@nongnu.org; Mon, 05 Aug 2013 08:37:48 -0400 Received: by mail-ve0-f174.google.com with SMTP id d10so2991008vea.19 for ; Mon, 05 Aug 2013 05:37:48 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: References: <1375701492-21759-1-git-send-email-peter.maydell@linaro.org> <1375701492-21759-3-git-send-email-peter.maydell@linaro.org> Date: Mon, 5 Aug 2013 18:07:48 +0530 Message-ID: From: Anup Patel Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: [Qemu-devel] [PATCH v4 2/2] ARM: Add 'virt' platform List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Peter Maydell Cc: "patches@linaro.org" , qemu-devel@nongnu.org, "kvmarm@lists.cs.columbia.edu" On Mon, Aug 5, 2013 at 5:58 PM, Peter Maydell wrote: > On 5 August 2013 13:22, Anup Patel wrote: >> On Mon, Aug 5, 2013 at 5:31 PM, Peter Maydell wrote: >>> On 5 August 2013 12:48, Anup Patel wrote: >>>>> +static const MemMapEntry a15memmap[] = { >>>>> + [VIRT_FLASH] = { 0, 0x100000 }, >>>> >>>> IMHO, 1 MB of flash is small for possible future expansion. If mach-virt >>>> becomes popular then we can expect people running UBoot or UEFI or >>>> .... from this flash. >>>> >>>> I think having 16 MB of flash would be good because it is multiple of >>>> 2 MB hence we can also create section entries for it in Stage2 TTBL. >>> >>> Seems reasonable. >>> >>>>> + [VIRT_CPUPERIPHS] = { 0x100000, 0x8000 }, >>>> >>>> I would suggest to start peripheral space at 2 MB boundary and also >>>> have its total size in multiple of 2 MB. >>> >>> The total size here is fixed by the CPU hardware -- an A15's >>> private peripheral space is only 0x8000 in size. >> >> Does this mean, mach-virt address space is Cortex-A15 specific ? > > The patch has support for an array of VirtBoardInfo structs, > each of which has its own memmap. The only entry at the > moment is for the A15. > >> What about Cortex-A7 and Cortex-A12 ? > > QEMU supports neither of these CPUs. The A7's the same as > the A15, though. > >> If above is a mandatory constraint then we can have peripheral space divide >> into two parts: >> 1. Essential (or MPCore) peripherals: For now only GIC belongs here. Other >> things that fit here is Watchdog and Local timers but this are redundant for >> mach-virt. This space can be only 0x8000 in size as required by Cortex-A15. >> 2. General peripherals: All VirtIO devices would belong here. In addition, >> users can also add devices to this space using QEMU command line. > > Er, this is what the patch already does. The "CPUPERIPHS" > bit is specifically for the CPU's private peripheral region. > > You can't add an MMIO device on the QEMU command line, there's > no way to wire up the memory regions and IRQs. > >>> Why does each individual peripheral have to be at a 2MB boundary? >>> I would expect the kernel to just have a single "nothing mapped" >>> here stage 2 table entry (or entries) covering the whole of the >>> mmio peripheral region regardless of how many devices happen >>> to be inside it. >> >> Yes, this seem a little over-kill but we can atleast have peripheral space to >> be 2MB aligned with total size in multiple of 2MB. > > I really don't want to eat 2MB for each virtio-mmio transport > in a 32 bit address space, it seems hugely wasteful unless > there's a good reason to do it. I am not suggesting to give 2MB space to each virtio-mmio transport. What I really meant was to start VIRT_MMIO space (where all the virtio-mmio transport would be added) to start at 2MB aligned address and have total size (include all virtio-mmio transports) to be in-multiple of 2MB so that we can trap access to all virtio-mmio transports using 1-2 2MB entries in Stage2. > > -- PMM --Anup