From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:45915) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1g82QQ-0001E7-FY for qemu-devel@nongnu.org; Thu, 04 Oct 2018 08:08:15 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1g82QN-00053O-7b for qemu-devel@nongnu.org; Thu, 04 Oct 2018 08:08:14 -0400 References: <1530602398-16127-1-git-send-email-eric.auger@redhat.com> <43a03645-fa17-3274-9a66-502acc27b2ee@redhat.com> <20181004131150.3de8174a@redhat.com> <3ee4a49b-77fa-da05-262a-ab75ef1ade84@redhat.com> From: Auger Eric Message-ID: Date: Thu, 4 Oct 2018 14:07:52 +0200 MIME-Version: 1.0 In-Reply-To: <3ee4a49b-77fa-da05-262a-ab75ef1ade84@redhat.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [RFC v3 00/15] ARM virt: PCDIMM/NVDIMM at 2TB List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: David Hildenbrand , Igor Mammedov Cc: eric.auger.pro@gmail.com, qemu-devel@nongnu.org, qemu-arm@nongnu.org, peter.maydell@linaro.org, shameerali.kolothum.thodi@huawei.com, wei@redhat.com, drjones@redhat.com, Ard Biesheuvel , "Dr. David Alan Gilbert" , agraf@suse.de, Laszlo Ersek , david@gibson.dropbear.id.au Hi David, On 10/4/18 2:02 PM, David Hildenbrand wrote: >>>> Alternative to have a split model is having a floating RAM base for a >>>> contiguous initial + device memory (contiguity actually depends on >>>> initial RAM size alignment too). This requires significant changes in FW >>>> and also potentially impacts the legacy virt address map as we need to >>>> pass the RAM floating base address in some way (using an SRAM at 1GB) or >>>> using fw_cfg. Is it worth the effort? Also, Peter/Laszlo mentioned their >>>> reluctance to move the RAM earlier >>> Drew is working on it, lets see outcome first. >>> >>> We actually may try implement single region that uses pc-dimm for >>> all memory (including initial) and be still compatible with legacy layout >>> as far as legacy mode sticks to the current RAM limit and device memory >>> region is put at the current RAM base. >>> When flexible RAM base is available, we will move that region to >>> non legacy layout at 2TB (or wherever). >> >> Oh I did not understand you wanted to also replace the initial memory by >> device memory. So we would switch from a pure static initial RAM setup >> to a pure dynamic device memory setup. Looks quite drastic a change to >> me. As mentionned I am concerned about complexifying the qemu cmd line >> and I asked livirt guys about the induced pain. > > One idea was to create internal memory devices (e.g. "memory chip") that > get created and placed automatically in guest physical address space. > These devices would not require a change on the cmdline, they would be > created automatically from the existing parameters. > > The machine device memory region would than be one big region for both, > internal memory devices and external ("plugged") memory devices a.k.a. > dimms. > > I guess that will require more work to be done. OK interesting. Yes this adds some more work on the pile ... Thanks Eric > >> >> Thank you for your feedbacks >> >> Eric > >