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

[Haozhong Zhang <haozhong.zhang@intel.com>]

On 02/05/16 09:40, Ross Philipson wrote:
> On 02/03/2016 09:09 AM, Andrew Cooper wrote:
[...]
> >I agree.
> >
> >There has to be a single entity responsible for collating the eventual
> >ACPI handed to the guest, and this is definitely HVMLoader.
> >
> >However, it is correct that Qemu create the ACPI tables for the devices
> >it emulates for the guest.
> >
> >We need to agree on a mechanism whereby each entity can provide their
> >own subset of the ACPI tables to HVMLoader, and have HVMLoader present
> >the final set properly to the VM.
> >
> >There is an existing usecase of passing the Host SLIC table to a VM, for
> >OEM Versions of Windows.  I believe this is achieved with
> >HVM_XS_ACPI_PT_{ADDRESS,LENGTH}, but that mechanism is a little
> >inflexible and could probably do with being made a little more generic.
>
> A while back I added a generic mechanism to load extra ACPI tables into a
> guest, configurable at runtime. It looks like the functionality is still
> present. That might be an option.
>
> Also, following the thread, it wasn't clear if some of the tables like the
> SSDT for the NVDIMM device and it's _FIT/_DSM methods were something that
> could be statically created at build time. If it is something that needs to
> be generated at runtime (e.g. platform specific), I have a library that can
> generate any AML on the fly and create SSDTs.
>
> Anyway just FYI in case this is helpful.
>

Hi Ross,

Thanks for the information!

SSDT for NVDIMM devices can not be created statically, because the
number of some items in it can not be determined at build time. For
example, the number of NVDIMM ACPI namespace devices (_DSM is under it)
defined in SSDT is determined by the number of vNVDIMM devices in domain
configuration. FYI, a sample SSDT for NVDIMM looks like

  Scope (\_SB){
      Device (NVDR) // NVDIMM Root device
      {
          Name (_HID, “ACPI0012”)
          Method (_STA) {...}
          Method (_FIT) {...}
          Method (_DSM, ...) {
              ...
          }
      }

      Device (NVD0) // 1st NVDIMM Device
      {
          Name(_ADR, h0)
          Method (_DSM, ...) {
              ...
          }
      }

      Device (NVD1) // 2nd NVDIMM Device
      {
          Name(_ADR, h1)
          Method (_DSM, ...) {
              ...
          }
      }

      ...
  }

I had ported QEMU's AML builder code as well as NVDIMM ACPI building
code to hvmloader and it did work, but then there was too much
duplicated code for vNVDIMM between QEMU and hvmloader for vNVDIMM.
Therefore, I prefer to let QEMU that emulates vNVDIMM devices
to build those tables, as in Andrew and Jan's replies.

Thanks,
Haozhong

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