Re: [Xen-devel] [RFC Design Doc] Add vNVDIMM support for Xen

[Haozhong Zhang <haozhong.zhang@xxxxxxxxx>]

On 02/24/16 09:00, Ross Philipson wrote:
[...]
> > For each NVDIMM device defined in NFIT, there is a ACPI namespace device
> > (e.g. NVD0, NVD1) under the root NVDIMM device (NVDR). Because the
> > number of vNVDIMM devices are unknown at build time, we can not
> > determine whether and how many NVDIMM ACPI namespace devices should be
> > defined in the pre-generated SSDT.
> 
> We have dealt with the exact same issue in the past (though it concerned
> WMI ACPI devices). The layout and number of these devices and their
> methods was very platform dependent as this seems to be. Thus we
> generated an SSDT at runtime to reflect the underlying platform. At that
> time we had to write an AML generator but as noted earlier, SeaBIOS now
> seems to have a fairly complete one. This would allow you to do create
> the proper number of NVDx devices and set the desired addresses at runtime.
>

Thanks for the information. I just did a quick grep on SeaBIOS code and
found some AML related code in scripts/acpi_extract.py. Is this the AML
generator you mean?

> If you have to do it statically at build time you will have to pick a
> max number of possible NVDx devices and make some of them report they
> are not there (e.g. w/ the _STA methods possibly). In this case you
> could extend ACPI_INFO_PHYSICAL_ADDRESS or create your own IO/Memory
> OpRegion that you handle at runtime. I would personally go for the first
> option.
>

_STA does not work, because the individual NVDIMM ACPI namespace device
(NVDx) does no provide _STA method. In addition, ACPI spec does not
define any mechanism to check the presence of an individual NVDx.

Haozhong

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel