Re: Microsoft and Intel NVDIMM ACPI _DSM interfaces status?

[Stefan Hajnoczi]

On Thu, Mar 18, 2021 at 02:00:29AM +0000, Dexuan Cui wrote:
> > 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.
> "

Thank you, Laszlo and Dexuan!

I wonder if there are existing Windows drivers available that work with
QEMU's NVDIMM device. Otherwise it may make sense to implement the
Hyper-V interface.

Stefan

Stefan

signature.asc
Description: PGP signature