From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:58053) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zbspf-000110-Fx for qemu-devel@nongnu.org; Tue, 15 Sep 2015 12:11:48 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Zbspa-0007Ex-HE for qemu-devel@nongnu.org; Tue, 15 Sep 2015 12:11:47 -0400 Received: from mx1.redhat.com ([209.132.183.28]:33184) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zbspa-0007En-CF for qemu-devel@nongnu.org; Tue, 15 Sep 2015 12:11:42 -0400 References: <1439563931-12352-1-git-send-email-guangrong.xiao@linux.intel.com> <1439563931-12352-9-git-send-email-guangrong.xiao@linux.intel.com> <20150907161155.154a02f8@nial.brq.redhat.com> From: Paolo Bonzini Message-ID: <55F84338.2010408@redhat.com> Date: Tue, 15 Sep 2015 18:11:36 +0200 MIME-Version: 1.0 In-Reply-To: <20150907161155.154a02f8@nial.brq.redhat.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH v2 08/18] nvdimm: init backend memory mapping and config data area List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Igor Mammedov , Xiao Guangrong Cc: ehabkost@redhat.com, kvm@vger.kernel.org, mst@redhat.com, gleb@kernel.org, mtosatti@redhat.com, qemu-devel@nongnu.org, stefanha@redhat.com, rth@twiddle.net On 07/09/2015 16:11, Igor Mammedov wrote: > > here is common concepts that could be reused. > - on physical system both DIMM and NVDIMM devices use > the same slots. We could share QEMU's '-m slots' option between > both devices. An alternative to not sharing would be to introduce > '-machine nvdimm_slots' option. > And yes, we need to know number of NVDIMMs to describe > them all in ACPI table (taking in amount future hotplug > include in this possible NVDIMM devices) > I'd go the same way as on real hardware on make them share the same slots. > - they share the same physical address space and limits > on how much memory system can handle. So I'd suggest sharing existing > '-m maxmem' option and reuse hotplug_memory address space. I agree, and the slot number also provide a nice way to build a consistent memory region name across multiple systems. Paolo