From mboxrd@z Thu Jan 1 00:00:00 1970 From: Igor Mammedov Subject: Re: [PATCH v2 6/8] pc: memhp: do not export nvdimm's memory via _CRS Date: Mon, 10 Oct 2016 14:47:10 +0200 Message-ID: <20161010144710.5be84cfb@nial.brq.redhat.com> References: <1470984850-66891-1-git-send-email-guangrong.xiao@linux.intel.com> <1470984850-66891-7-git-send-email-guangrong.xiao@linux.intel.com> <20161003152154.03766fc1@nial.brq.redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: pbonzini@redhat.com, gleb@kernel.org, mtosatti@redhat.com, stefanha@redhat.com, mst@redhat.com, rth@twiddle.net, ehabkost@redhat.com, dan.j.williams@intel.com, kvm@vger.kernel.org, qemu-devel@nongnu.org To: Xiao Guangrong Return-path: Received: from mx1.redhat.com ([209.132.183.28]:60090 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751352AbcJJMrP (ORCPT ); Mon, 10 Oct 2016 08:47:15 -0400 In-Reply-To: Sender: kvm-owner@vger.kernel.org List-ID: On Sat, 8 Oct 2016 15:42:41 +0800 Xiao Guangrong wrote: > On 10/03/2016 09:21 PM, Igor Mammedov wrote: > > On Fri, 12 Aug 2016 14:54:08 +0800 > > Xiao Guangrong wrote: > > > >> nvdimm's memory info can not exported via _CRS, instead, it is reported > >> by NFIT/FIT > >> > >> This patch let _CRS return zero for both memory address and memory size > >> if it is a nvdimm device inserted to the slot > > I'm not sure if it's right thing to do. > > As it's relatively new, spec isn't clear about NVDIMM hotplug > > process and how it's related to PNP0C80 memory devices. > > > > The thing is that notify to PNP0C80 will trigger regular > > memory hotplug which would expect a valid _CRS and > > I won't even try to predict reaction of different guests > > on such behavior. > > > > So far exposing NFIT was sufficient for guest to work with > > NVDIMMs at startup. So I'd assume NVDIMM_ROOT._FIT() would > > provide sufficient info to hot-plug NVDIMM and allow > > NVDIMM driver to handle it. > > > > The only case of using PNP0C80 with NVDIMM, I'd imagine, is > > when one would like to expose NVDIMM as conventional RAM and > > make guest OS use it as such, which is probably not what you'd > > intended do here. > > > > Question is should/could NVDIMM hotplug work without using > > PNP0C80? > > Some confusion i got when i was reading ACPI spec. I thing you > are right that notifying memory device (PNP0C80) is needed only > if the nvdimm is trying to export conventional RAM. > > > > > One could reuse/share memhotplug GPE._E03 to notify NVDIMM_ROOT > > but even that is not necessary as NVDIMM has its own QEMU<->guest > > interface and could just take the next free _E04 handler. > > So I'd suggest to redo this and 7/8 patches to implement > > independent (of memhotplug) NVDIMM hotplug as a starting point. > > Based on ACPI Spec, the memory device (PNP0C80) and nvdimm device > is notified by the same interruption: > > Scope (\_GPE) > { > Method (_L00) { > Notify (\_SB.NVDR, 0x80) // Notify to NVDIMM root device > Notify (\_SB.MEM0, 1) // Device Check to Memory Module > } > } > > So, it is better to reuse _E03 and only notify NVDIMM device if the > hotplug event is triggered on a slot with nvdimm device attached? It's only an example in spec but there isn't requirement to do it that way. So I'd use a separate handler for now (we can always chain calls in future is need arises or merge them together) From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:50378) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1btZzE-0005FO-Ns for qemu-devel@nongnu.org; Mon, 10 Oct 2016 08:47:21 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1btZz9-00046R-OK for qemu-devel@nongnu.org; Mon, 10 Oct 2016 08:47:19 -0400 Received: from mx1.redhat.com ([209.132.183.28]:36244) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1btZz9-00046F-EV for qemu-devel@nongnu.org; Mon, 10 Oct 2016 08:47:15 -0400 Date: Mon, 10 Oct 2016 14:47:10 +0200 From: Igor Mammedov Message-ID: <20161010144710.5be84cfb@nial.brq.redhat.com> In-Reply-To: References: <1470984850-66891-1-git-send-email-guangrong.xiao@linux.intel.com> <1470984850-66891-7-git-send-email-guangrong.xiao@linux.intel.com> <20161003152154.03766fc1@nial.brq.redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH v2 6/8] pc: memhp: do not export nvdimm's memory via _CRS List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Xiao Guangrong Cc: pbonzini@redhat.com, gleb@kernel.org, mtosatti@redhat.com, stefanha@redhat.com, mst@redhat.com, rth@twiddle.net, ehabkost@redhat.com, dan.j.williams@intel.com, kvm@vger.kernel.org, qemu-devel@nongnu.org On Sat, 8 Oct 2016 15:42:41 +0800 Xiao Guangrong wrote: > On 10/03/2016 09:21 PM, Igor Mammedov wrote: > > On Fri, 12 Aug 2016 14:54:08 +0800 > > Xiao Guangrong wrote: > > > >> nvdimm's memory info can not exported via _CRS, instead, it is reported > >> by NFIT/FIT > >> > >> This patch let _CRS return zero for both memory address and memory size > >> if it is a nvdimm device inserted to the slot > > I'm not sure if it's right thing to do. > > As it's relatively new, spec isn't clear about NVDIMM hotplug > > process and how it's related to PNP0C80 memory devices. > > > > The thing is that notify to PNP0C80 will trigger regular > > memory hotplug which would expect a valid _CRS and > > I won't even try to predict reaction of different guests > > on such behavior. > > > > So far exposing NFIT was sufficient for guest to work with > > NVDIMMs at startup. So I'd assume NVDIMM_ROOT._FIT() would > > provide sufficient info to hot-plug NVDIMM and allow > > NVDIMM driver to handle it. > > > > The only case of using PNP0C80 with NVDIMM, I'd imagine, is > > when one would like to expose NVDIMM as conventional RAM and > > make guest OS use it as such, which is probably not what you'd > > intended do here. > > > > Question is should/could NVDIMM hotplug work without using > > PNP0C80? > > Some confusion i got when i was reading ACPI spec. I thing you > are right that notifying memory device (PNP0C80) is needed only > if the nvdimm is trying to export conventional RAM. > > > > > One could reuse/share memhotplug GPE._E03 to notify NVDIMM_ROOT > > but even that is not necessary as NVDIMM has its own QEMU<->guest > > interface and could just take the next free _E04 handler. > > So I'd suggest to redo this and 7/8 patches to implement > > independent (of memhotplug) NVDIMM hotplug as a starting point. > > Based on ACPI Spec, the memory device (PNP0C80) and nvdimm device > is notified by the same interruption: > > Scope (\_GPE) > { > Method (_L00) { > Notify (\_SB.NVDR, 0x80) // Notify to NVDIMM root device > Notify (\_SB.MEM0, 1) // Device Check to Memory Module > } > } > > So, it is better to reuse _E03 and only notify NVDIMM device if the > hotplug event is triggered on a slot with nvdimm device attached? It's only an example in spec but there isn't requirement to do it that way. So I'd use a separate handler for now (we can always chain calls in future is need arises or merge them together)