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

[Ross Philipson <ross.philipson@xxxxxxxxx>]

On 02/24/2016 11:42 AM, Haozhong Zhang wrote:
> 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?

Oh terribly sorry - I am talking about QEMU. The code in
hw/acpi/aml-build.c looks like it does a lot of what my library does. I
don't know how complete it is. For example I had to do a lot of work to
build resource packages and I have not found that yet. But it is a good
starting place.

> 
>> 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
> 


-- 
Ross Philipson

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