From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received-SPF: Pass (sender SPF authorized) identity=mailfrom; client-ip=209.132.183.28; helo=mx1.redhat.com; envelope-from=lersek@redhat.com; receiver=edk2-devel@lists.01.org Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ml01.01.org (Postfix) with ESMTPS id 91194202E59CA for ; Fri, 13 Oct 2017 12:37:23 -0700 (PDT) Received: from smtp.corp.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 2BF523E6; Fri, 13 Oct 2017 19:40:54 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 2BF523E6 Authentication-Results: ext-mx05.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx05.extmail.prod.ext.phx2.redhat.com; spf=fail smtp.mailfrom=lersek@redhat.com Received: from lacos-laptop-7.usersys.redhat.com (ovpn-123-190.rdu2.redhat.com [10.10.123.190]) by smtp.corp.redhat.com (Postfix) with ESMTP id A39B360BEC; Fri, 13 Oct 2017 19:40:49 +0000 (UTC) To: Ard Biesheuvel Cc: "Leif Lindholm (Linaro address)" , edk2-devel-01 , Drew Jones , qemu devel list , Peter Maydell , Igor Mammedov , Andrea Bolognani , libvirt devel References: <4cce2b8b-a411-bd5d-a06f-b0b80a5fb2f1@redhat.com> From: Laszlo Ersek Message-ID: <7b84a76d-7708-7c8c-8fcf-7fe5549ed43f@redhat.com> Date: Fri, 13 Oct 2017 21:40:47 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: X-Scanned-By: MIMEDefang 2.79 on 10.5.11.12 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.29]); Fri, 13 Oct 2017 19:40:54 +0000 (UTC) Subject: Re: dynamic DRAM base for ArmVirtQemu X-BeenThere: edk2-devel@lists.01.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: EDK II Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Oct 2017 19:37:23 -0000 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit On 10/13/17 15:21, Ard Biesheuvel wrote: > On 13 October 2017 at 13:51, Laszlo Ersek wrote: >> Hi Ard, Leif, >> >> the current physical memory map of the "virt" machine type doesn't leave >> much room for ECAM / MMCONFIG, which limits the number of PCI Express >> root ports and downstream ports (each port takes a separate bus number, >> and each bus number eats up a chunk of the ECAM area). Also, each port >> can only accommodate a single PCI Express device. In practice this >> limits the number of (hot-pluggable) PCIe devices to approx. 16, which >> is deemed by some "not scaleable enough". (For devices that only need to >> be cold-plugged, they can be placed directly on the root complex, as >> integrated devices, possibly grouping them into multifunction devices >> even; so those don't need bus numbers.) >> >> In order to grow the MMCONFIG area (and for some other reasons >> possibly), the phys memmap of "virt" should be shuffled around a bit. >> This affects the "system" DRAM too. >> > > Is it really necessary to put the ECAM area below 4 GB? For ARM, I > understand this would be an issue, but does the spec actually mandate > anything like this? No, I don't think it's inherently necessary to put ECAM under 4GB. It's just that I approached the problem such that the firmware would be burdened with the lion's share of the complexity, in order to keep things "compatible" for the rest of the guest world. (Speaking personally, I'd absolutely prefer to keep the DRAM base untouched, at 1GB, but I was invited to take a good hard look at what moving the DRAM base would take for the firmware, and I made an honest effort to determine the impact. It doesn't imply that I like the result in the least, or that I personally subscribe to the idea.) Thanks! Laszlo