From mboxrd@z Thu Jan 1 00:00:00 1970 From: Xiao Guangrong Subject: Re: [Qemu-devel] [PATCH v2 06/11] nvdimm acpi: initialize the resource used by NVDIMM ACPI Date: Thu, 18 Feb 2016 12:03:36 +0800 Message-ID: <56C54298.3000904@linux.intel.com> References: <20160215111705-mutt-send-email-mst@redhat.com> <56C1A4D2.3060402@linux.intel.com> <20160215114742.382c951e@nial.brq.redhat.com> <20160215133722-mutt-send-email-mst@redhat.com> <20160215143234.29320a5f@nial.brq.redhat.com> <56C1F469.2040602@linux.intel.com> <20160215182404.0878474f@nial.brq.redhat.com> <56C21A7D.5040902@linux.intel.com> <20160216120047.5a50eccf@nial.brq.redhat.com> <56C3D522.6090401@linux.intel.com> <20160217192356-mutt-send-email-mst@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: QUOTED-PRINTABLE Cc: Igor Mammedov , ehabkost@redhat.com, kvm@vger.kernel.org, gleb@kernel.org, mtosatti@redhat.com, qemu-devel@nongnu.org, stefanha@redhat.com, pbonzini@redhat.com, dan.j.williams@intel.com, rth@twiddle.net To: "Michael S. Tsirkin" Return-path: Received: from mga09.intel.com ([134.134.136.24]:44010 "EHLO mga09.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1423667AbcBRELo (ORCPT ); Wed, 17 Feb 2016 23:11:44 -0500 In-Reply-To: <20160217192356-mutt-send-email-mst@redhat.com> Sender: kvm-owner@vger.kernel.org List-ID: On 02/18/2016 01:26 AM, Michael S. Tsirkin wrote: > On Wed, Feb 17, 2016 at 10:04:18AM +0800, Xiao Guangrong wrote: >>>>> As for the rest could that commands go via MMIO that we usually >>>>> use for control path? >>>> >>>> So both input data and output data go through single MMIO, we need= to >>>> introduce a protocol to pass these data, that is complex? >>>> >>>> And is any MMIO we can reuse (more complexer=EF=BC=9F) or we shoul= d allocate this >>>> MMIO page =EF=BC=88the old question - where to allocated?=EF=BC=89= ? >>> Maybe you could reuse/extend memhotplug IO interface, >>> or alternatively as Michael suggested add a vendor specific PCI_Con= fig, >>> I'd suggest PM device for that (hw/acpi/[piix4.c|ihc9.c]) >>> which I like even better since you won't need to care about which p= orts >>> to allocate at all. >> >> Well, if Michael does not object, i will do it in the next version. = :) > > Sorry, the thread's so long by now that I'm no longer sure what does = "it" refer to. Never mind i saw you were busy on other loops. "It" means the suggestion of Igor that "map each label area right after= each NVDIMM's data memory" so we do not emulate it in QEMU and is good for t= he performance of label these are the points i like. However it also brings complexity= /limitation for later DSM commands supports since both dsm input & output need to go th= rough single MMIO. Your idea?