Re: [Qemu-devel] [RFC v3 00/15] ARM virt: PCDIMM/NVDIMM at 2TB

From: Auger Eric <eric.auger@redhat.com>
To: David Hildenbrand <david@redhat.com>,
	Igor Mammedov <imammedo@redhat.com>
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 <ard.biesheuvel@linaro.org>,
	"Dr. David Alan Gilbert" <dgilbert@redhat.com>,
	agraf@suse.de, Laszlo Ersek <lersek@redhat.com>,
	david@gibson.dropbear.id.au
Subject: Re: [Qemu-devel] [RFC v3 00/15] ARM virt: PCDIMM/NVDIMM at 2TB
Date: Thu, 4 Oct 2018 14:07:52 +0200	[thread overview]
Message-ID: <c31b2bee-457f-b262-7173-9fe262f0a332@redhat.com> (raw)
In-Reply-To: <3ee4a49b-77fa-da05-262a-ab75ef1ade84@redhat.com>

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
> 
> 