| Message ID | 1470984850-66891-7-git-send-email-guangrong.xiao@linux.intel.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
On Fri, 12 Aug 2016 14:54:08 +0800 Xiao Guangrong <guangrong.xiao@linux.intel.com> 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? 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. > > Signed-off-by: Xiao Guangrong <guangrong.xiao@linux.intel.com> > --- > hw/acpi/memory_hotplug.c | 16 ++++++++++++---- > include/hw/acpi/memory_hotplug.h | 1 + > 2 files changed, 13 insertions(+), 4 deletions(-) > > diff --git a/hw/acpi/memory_hotplug.c b/hw/acpi/memory_hotplug.c > index ec4e64b..73fa62d 100644 > --- a/hw/acpi/memory_hotplug.c > +++ b/hw/acpi/memory_hotplug.c > @@ -2,6 +2,7 @@ > #include "hw/acpi/memory_hotplug.h" > #include "hw/acpi/pc-hotplug.h" > #include "hw/mem/pc-dimm.h" > +#include "hw/mem/nvdimm.h" > #include "hw/boards.h" > #include "hw/qdev-core.h" > #include "trace.h" > @@ -41,6 +42,7 @@ void acpi_memory_ospm_status(MemHotplugState *mem_st, ACPIOSTInfoList ***list) > static uint64_t acpi_memory_hotplug_read(void *opaque, hwaddr addr, > unsigned int size) > { > + uint64_t maddr, msize; > uint32_t val = 0; > MemHotplugState *mem_st = opaque; > MemStatus *mdev; > @@ -53,21 +55,25 @@ static uint64_t acpi_memory_hotplug_read(void *opaque, hwaddr addr, > > mdev = &mem_st->devs[mem_st->selector]; > o = OBJECT(mdev->dimm); > + maddr = o && !mdev->is_nvdimm ? object_property_get_int(o, > + PC_DIMM_ADDR_PROP, NULL) : 0; > + msize = o && !mdev->is_nvdimm ? object_property_get_int(o, > + PC_DIMM_SIZE_PROP, NULL) : 0; > switch (addr) { > case 0x0: /* Lo part of phys address where DIMM is mapped */ > - val = o ? object_property_get_int(o, PC_DIMM_ADDR_PROP, NULL) : 0; > + val = maddr; > trace_mhp_acpi_read_addr_lo(mem_st->selector, val); > break; > case 0x4: /* Hi part of phys address where DIMM is mapped */ > - val = o ? object_property_get_int(o, PC_DIMM_ADDR_PROP, NULL) >> 32 : 0; > + val = maddr >> 32; > trace_mhp_acpi_read_addr_hi(mem_st->selector, val); > break; > case 0x8: /* Lo part of DIMM size */ > - val = o ? object_property_get_int(o, PC_DIMM_SIZE_PROP, NULL) : 0; > + val = msize; > trace_mhp_acpi_read_size_lo(mem_st->selector, val); > break; > case 0xc: /* Hi part of DIMM size */ > - val = o ? object_property_get_int(o, PC_DIMM_SIZE_PROP, NULL) >> 32 : 0; > + val = msize >> 32; > trace_mhp_acpi_read_size_hi(mem_st->selector, val); > break; > case 0x10: /* node proximity for _PXM method */ > @@ -78,6 +84,7 @@ static uint64_t acpi_memory_hotplug_read(void *opaque, hwaddr addr, > val |= mdev->is_enabled ? 1 : 0; > val |= mdev->is_inserting ? 2 : 0; > val |= mdev->is_removing ? 4 : 0; > + val |= mdev->is_nvdimm ? 16 : 0; > trace_mhp_acpi_read_flags(mem_st->selector, val); > break; > default: > @@ -245,6 +252,7 @@ void acpi_memory_plug_cb(HotplugHandler *hotplug_dev, MemHotplugState *mem_st, > > mdev->dimm = dev; > mdev->is_enabled = true; > + mdev->is_nvdimm = object_dynamic_cast(OBJECT(dev), TYPE_NVDIMM); > if (dev->hotplugged) { > mdev->is_inserting = true; > acpi_send_event(DEVICE(hotplug_dev), ACPI_MEMORY_HOTPLUG_STATUS); > diff --git a/include/hw/acpi/memory_hotplug.h b/include/hw/acpi/memory_hotplug.h > index d2c7452..69a05df 100644 > --- a/include/hw/acpi/memory_hotplug.h > +++ b/include/hw/acpi/memory_hotplug.h > @@ -17,6 +17,7 @@ typedef struct MemStatus { > bool is_enabled; > bool is_inserting; > bool is_removing; > + bool is_nvdimm; > uint32_t ost_event; > uint32_t ost_status; > } MemStatus; -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 10/03/2016 09:21 PM, Igor Mammedov wrote: > On Fri, 12 Aug 2016 14:54:08 +0800 > Xiao Guangrong <guangrong.xiao@linux.intel.com> 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? -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Sat, 8 Oct 2016 15:42:41 +0800 Xiao Guangrong <guangrong.xiao@linux.intel.com> wrote: > On 10/03/2016 09:21 PM, Igor Mammedov wrote: > > On Fri, 12 Aug 2016 14:54:08 +0800 > > Xiao Guangrong <guangrong.xiao@linux.intel.com> 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) -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 10/10/2016 08:47 PM, Igor Mammedov wrote: >> 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) No objection. Will do it. -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
diff --git a/hw/acpi/memory_hotplug.c b/hw/acpi/memory_hotplug.c index ec4e64b..73fa62d 100644 --- a/hw/acpi/memory_hotplug.c +++ b/hw/acpi/memory_hotplug.c @@ -2,6 +2,7 @@ #include "hw/acpi/memory_hotplug.h" #include "hw/acpi/pc-hotplug.h" #include "hw/mem/pc-dimm.h" +#include "hw/mem/nvdimm.h" #include "hw/boards.h" #include "hw/qdev-core.h" #include "trace.h" @@ -41,6 +42,7 @@ void acpi_memory_ospm_status(MemHotplugState *mem_st, ACPIOSTInfoList ***list) static uint64_t acpi_memory_hotplug_read(void *opaque, hwaddr addr, unsigned int size) { + uint64_t maddr, msize; uint32_t val = 0; MemHotplugState *mem_st = opaque; MemStatus *mdev; @@ -53,21 +55,25 @@ static uint64_t acpi_memory_hotplug_read(void *opaque, hwaddr addr, mdev = &mem_st->devs[mem_st->selector]; o = OBJECT(mdev->dimm); + maddr = o && !mdev->is_nvdimm ? object_property_get_int(o, + PC_DIMM_ADDR_PROP, NULL) : 0; + msize = o && !mdev->is_nvdimm ? object_property_get_int(o, + PC_DIMM_SIZE_PROP, NULL) : 0; switch (addr) { case 0x0: /* Lo part of phys address where DIMM is mapped */ - val = o ? object_property_get_int(o, PC_DIMM_ADDR_PROP, NULL) : 0; + val = maddr; trace_mhp_acpi_read_addr_lo(mem_st->selector, val); break; case 0x4: /* Hi part of phys address where DIMM is mapped */ - val = o ? object_property_get_int(o, PC_DIMM_ADDR_PROP, NULL) >> 32 : 0; + val = maddr >> 32; trace_mhp_acpi_read_addr_hi(mem_st->selector, val); break; case 0x8: /* Lo part of DIMM size */ - val = o ? object_property_get_int(o, PC_DIMM_SIZE_PROP, NULL) : 0; + val = msize; trace_mhp_acpi_read_size_lo(mem_st->selector, val); break; case 0xc: /* Hi part of DIMM size */ - val = o ? object_property_get_int(o, PC_DIMM_SIZE_PROP, NULL) >> 32 : 0; + val = msize >> 32; trace_mhp_acpi_read_size_hi(mem_st->selector, val); break; case 0x10: /* node proximity for _PXM method */ @@ -78,6 +84,7 @@ static uint64_t acpi_memory_hotplug_read(void *opaque, hwaddr addr, val |= mdev->is_enabled ? 1 : 0; val |= mdev->is_inserting ? 2 : 0; val |= mdev->is_removing ? 4 : 0; + val |= mdev->is_nvdimm ? 16 : 0; trace_mhp_acpi_read_flags(mem_st->selector, val); break; default: @@ -245,6 +252,7 @@ void acpi_memory_plug_cb(HotplugHandler *hotplug_dev, MemHotplugState *mem_st, mdev->dimm = dev; mdev->is_enabled = true; + mdev->is_nvdimm = object_dynamic_cast(OBJECT(dev), TYPE_NVDIMM); if (dev->hotplugged) { mdev->is_inserting = true; acpi_send_event(DEVICE(hotplug_dev), ACPI_MEMORY_HOTPLUG_STATUS); diff --git a/include/hw/acpi/memory_hotplug.h b/include/hw/acpi/memory_hotplug.h index d2c7452..69a05df 100644 --- a/include/hw/acpi/memory_hotplug.h +++ b/include/hw/acpi/memory_hotplug.h @@ -17,6 +17,7 @@ typedef struct MemStatus { bool is_enabled; bool is_inserting; bool is_removing; + bool is_nvdimm; uint32_t ost_event; uint32_t ost_status; } MemStatus;
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 Signed-off-by: Xiao Guangrong <guangrong.xiao@linux.intel.com> --- hw/acpi/memory_hotplug.c | 16 ++++++++++++---- include/hw/acpi/memory_hotplug.h | 1 + 2 files changed, 13 insertions(+), 4 deletions(-)