On 10/03/2016 09:21 PM, Igor Mammedov wrote:
On Fri, 12 Aug 2016 14:54:08 +0800
Xiao Guangrong <guangrong.xiao@xxxxxxxxxxxxxxx> 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@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
