RE: Microsoft and Intel NVDIMM ACPI _DSM interfaces status?

[Dexuan Cui]

> From: Laszlo Ersek <lersek@redhat.com>
> Sent: Wednesday, March 17, 2021 3:45 PM
> > The specs for the Intel interface are available here:
> > ...
> > 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.

I'm not sure why this happens -- sorry, I have no Windows knowledge.
 
> > Should QEMU emulate both of them to make running Windows guests easy?

I'm not sure about the background here, but since it looks like QEMU is already
able to emulate the Intel NVDIMM, I suppose it should be quick to add the
emulation of the Hyper-V NVDIMM. I think they're pretty similar, and the
_DSM interface supported by Hyper-V NVDIMM is simple.
 
> 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

Hi Laszlo, I'm not 100% sure, but I guess your may be correct.

BTW, earlier in 2019, we made the below patches (which are in the mainline):

2019-02-28    libnvdimm/btt: Fix LBA masking during 'free list' population
2019-02-12    acpi/nfit: Require opt-in for read-only label configurations
2019-02-02    libnvdimm/dimm: Add a no-BLK quirk based on NVDIMM family
2019-01-29    nfit: Add Hyper-V NVDIMM DSM command set to white list
2019-01-29    nfit: acpi_nfit_ctl(): Check out_obj->type in the right place

The patches improve the interoperability between Windows VM and 
Linux VM, e.g. the same Hyper-V NVDIMM device can work this way:
the Windows VM creates an NTFS partition based on the device, and
creates a text file in the partition, and later we shut down the Windows VM
and assign the device to Linux VM, and Linux VM is able to read the text file.

Before the patches, IIRC, Linux VM could only use the Hyper-V NVIDMM
device in label-less mode.

Let me share some old 2019 notes about Hyper-V NVDIMM, in case the
info may be helpful to you: 

"
In Linux VM, IMO the label-less mode is preferred for Hyper-V NVDIMM,
because Hyper-V does not support _LSW (I'm not sure about the latest
status), so Dan made the patch "acpi/nfit: Require opt-in for read-only
label configurations" to not use the Hyper-V label info, by default.
In label-less mode, when creating a namespace, Linux can set it to
one of the 4 namespace modes: fsdax, devdax, sector, and raw (these
namespace modes are Linux-specific and can not be recognized
by Windows.). 

With the "nfit.force_labels" bootup-time kernel parameter, Linux can
be forced to be in label mode, and then if Hyper-V initializes the 4KB
BTT Info Block(s) with the standard EFI_BTT_ABSTRACTION_GUID
(which is defined in UEFI 2.7 spec), we're supposed to support the
"interoperability" between Windows VM and Linux VM.

Note: label-less mode is incompatible with label mode. A namespace
created in one mode can't be recognized when Linux runs in the other
mode. In label mode, so far, only 2 namespace modes (raw and sector)
can be supported by the Hyper-V NVDIMM, because Hyper-V doesn't
support _LSW, yet. If Hyper-V sets the EFI_BTT_ABSTRACTION_GUID,
the namespace is "BTT-capable" and can be in sector namespace
mode, otherwise it's in raw namespace mode.

After a Windows VM initializes a BTT-capable namespace in a Hyper-V
NVDIMM device by creating a NTFS file system in the namespace, we
can re-assign the Hyper-V NVDIMM device to Linux VM, and in label
mode Linux VM is supposed to be able to read and write the files in
the NTFS file system.
"

Thanks,
-- Dexuan