Re: Microsoft and Intel NVDIMM ACPI _DSM interfaces status?

[Laszlo Ersek]

(Adding Dexuan Cui to the CC list, comments below.)

On 03/17/21 12:49, Stefan Hajnoczi wrote:
> Hi,
> Microsoft and Intel developed two different ACPI NVDIMM _DSM
> interfaces.
>
> The specs for the Intel interface are available here:
> https://pmem.io/documents/NVDIMM_DSM_Interface_Example.pdf
>
> This is the interface that QEMU emulates. It has been reported that
> Windows 2016 Server and 2019 Server guests do not recognize QEMU's
> emulated NVDIMM devices using the Microsoft driver.

The Microsoft specification seems to be available at:

  https://uefi.org/NVDIMM%20RFIC%20Registry
  ->
  https://uefi.org/RFIC_LIST
  ->
  
https://www.uefi.org/sites/default/files/resources/_DSM%20for%20Virtual%20NVDIMMs%20v1.01.docx

It defines:

- Region Format Interface Code (RFIC) 0x1901,

- with a _DSM command set (for non-root devices) that is identified by
  UUID 5746C5F2-A9A2-4264-AD0E-E4DDC9E09E80.

On the other hand, the Intel document defines:

- RFIC 0x0201,

- with a _DSM command set (for non-root devices) that is identified by
  UUID 4309AC30-0D11-11E4-9191-0800200C9A66.

In the Linux kernel,

- the Microsoft UUID is called UUID_NFIT_DIMM_N_HYPERV (1194c4133195,
  "nfit: Add Hyper-V NVDIMM DSM command set to white list", 2019-01-29),

- while the Intel one is called UUID_NFIT_DIMM (commit b94d5230d06e,
  "libnvdimm, nfit: initial libnvdimm infrastructure and NFIT support",
  2015-06-24).

An interesting excerpt from commit 1194c4133195:

> +        * There are 4 "legacy" NVDIMM command sets
> +        * (NVDIMM_FAMILY_{INTEL,MSFT,HPE1,HPE2}) that were created before
> +        * an EFI working group was established to constrain this
> +        * proliferation. The nfit driver probes for the supported command
> +        * set by GUID. Note, if you're a platform developer looking to add
> +        * a new command set to this probe, consider using an existing set,
> +        * or otherwise seek approval to publish the command set at
> +        * http://www.uefi.org/RFIC_LIST.

And presently, the "official RFIC list" *only* contains Microsoft's
definition.

So my guess is that the QEMU device model (emulating Intel) predates
both the standardization and the registry, and that the Microsoft driver
only recognizes their own format (RFIC 0x1901 / UUID
5746C5F2-A9A2-4264-AD0E-E4DDC9E09E80).

Back to your email:

On 03/17/21 12:49, Stefan Hajnoczi wrote:
> I'd like to understand the path forward that will allow both Linux and
> Windows guests to successfully use QEMU's emulated NVDIMM device
> (https://gitlab.com/qemu-project/qemu/-/blob/master/hw/acpi/nvdimm.c).
>
> Are/have these two interfaces being/been unified?

I wouldn't think so. In the Linux kernel, UUID_NFIT_DIMM_N_HYPERV is
mapped to NFIT_DEV_DIMM_N_HYPERV is mapped to NVDIMM_FAMILY_HYPERV,
which seems to translate to "DSM mask" and "flags" manipulations...
which I don't understand. :)

FWIW, I believe the Linux kernel implements a "generic set" of NVDIMM
operations, and then it cherry-picks those features/operations that the
hardware (virtual or otherwise) advertizes, or seems to support.

This, and more closely the above-quoted code comment, appear to indicate
that there's no unification, at the interface level. The Linux guest
driver may have some implementation-level unification.

The first link I pasted above,
<https://uefi.org/NVDIMM%20RFIC%20Registry>, refers to "NVST Workgroup
Chairperson". After logging in to my <members.uefi.org> account, I
managed to resolve "NVST" as follows:

- ACPI Specification Working Group [ASWG]

  - NVDIMM Subteam [NVST]

    - https://members.uefi.org/apps/org/workgroup/nvst/description.php

      """
      Public Description

      The NVDIMM Subteam was created to review ACPI and UEFI related
      topics pertaining to persistent memory devices. All relevant ECR's
      need to be reviewed by this subcommittee prior to review by the
      USWG and ASWG. Please contact the group chair with questions or to
      add items to the regular meeting agenda.
      """

Some other abbreviations resolved, for interpreting the blurb:

- USWG: UEFI Spec Working Group

- ECR: Engineering Change Request -- basically a ticket filed for one of
  the UEFI, ACPI, and Platform Init specs, in the (members only) Mantis
  bug tracker, at <https://mantis.uefi.org/>. ECRs are usually proposed
  as stand-alone documents that are attached to Mantis tickets.


> Should QEMU emulate both of them to make running Windows guests easy?

In my (uneducated) opinion: yes. Microsoft standarized their Region
Format Interface, with their _DSM UUID and all; and right now, that spec
seems to be the *only* officially approved format in the RFIC registry.
So it's plausible to me that, unlike the Linux kernel, Microsoft's
driver doesn't support the -- technically unapproved, nonstandard --
Intel Region Format Interface.

Dexuan, please correct me if I'm wrong.

Thanks,
Laszlo