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? From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:45603) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aWFwO-0004Ie-TC for qemu-devel@nongnu.org; Wed, 17 Feb 2016 23:11:46 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aWFwL-0007LT-Bx for qemu-devel@nongnu.org; Wed, 17 Feb 2016 23:11:44 -0500 Received: from mga09.intel.com ([134.134.136.24]:55832) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aWFwL-0007LP-5d for qemu-devel@nongnu.org; Wed, 17 Feb 2016 23:11:41 -0500 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> From: Xiao Guangrong Message-ID: <56C54298.3000904@linux.intel.com> Date: Thu, 18 Feb 2016 12:03:36 +0800 MIME-Version: 1.0 In-Reply-To: <20160217192356-mutt-send-email-mst@redhat.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [Qemu-devel] [PATCH v2 06/11] nvdimm acpi: initialize the resource used by NVDIMM ACPI List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Michael S. Tsirkin" Cc: ehabkost@redhat.com, kvm@vger.kernel.org, gleb@kernel.org, mtosatti@redhat.com, qemu-devel@nongnu.org, stefanha@redhat.com, pbonzini@redhat.com, Igor Mammedov , dan.j.williams@intel.com, rth@twiddle.net 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？) or we should allocate this >>>> MMIO page （the old question - where to allocated?）? >>> Maybe you could reuse/extend memhotplug IO interface, >>> or alternatively as Michael suggested add a vendor specific PCI_Config, >>> 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 ports >>> 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 the 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 through single MMIO. Your idea?