(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
