qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Microsoft and Intel NVDIMM ACPI _DSM interfaces status?


From: Stefan Hajnoczi
Subject: Re: Microsoft and Intel NVDIMM ACPI _DSM interfaces status?
Date: Thu, 18 Mar 2021 19:28:28 +0000

On Wed, Mar 17, 2021 at 04:52:03PM -0700, Dan Williams wrote:
> On Wed, Mar 17, 2021 at 4:49 AM Stefan Hajnoczi <stefanha@redhat.com> 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.
> >
> > 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?
> 
> No, they service 2 different classes of NVDIMMs. The Microsoft
> specification was defined for NVDIMM-N devices that are the
> traditional battery/super-capacitor backed DDR with sometimes an equal
> amount of flash to squirrel away data to non-volatile media on power
> loss. The Intel one is for a persistent media class of device where
> there is no need to communicate health attributes like "energy source
> died" or "restore from flash" failed.
> 
> > Should QEMU emulate both of them to make running Windows guests easy?
> 
> Depends on how tolerant Windows is to different format-interface-code
> implementations and what QEMU should return on each of the functions
> it decides to implement.
> 
> Note that QEMU only implements a small subset of the Intel commands,
> i.e. just enough to provision namespaces in the NVDIMM label area.
> "NVDIMM label area" is a concept that is newer than the NVDIMM-N
> definition which is why you don't see labels mentioned in the
> Microsoft specification. Since then ACPI has developed common label
> area access methods, see "6.5.10 NVDIMM Label Methods" in the ACPI 6.4
> specification.
> 
> Note that you'll also see "9.20.8 NVDIMM Device Methods" in that spec
> for some health management commands that overlap what the Microsoft
> and Intel specs communicate. Linux does not support them since any
> platform that might support them will also support the Intel
> specification so there's no driving need for Linux to migrate. I do
> not know the status of that command support in Windows, or the HPE
> command support in Windows for that matter.
> 
> If you need to support guests that expect the Hyper-V command
> definition, and will fail to attach NVDIMM support in the absence of
> that definition then QEMU needs UUID_NFIT_DIMM_N_HYPERV support, note
> that is a different command set than even UUID_NFIT_DIMM_N_MSFT
> (include/acpi/acuuid.h). That would also require changes to virtual
> ACPI NFIT to advertise the correlated format interface code. There may
> be more... you would need someone from Hyper-V land to enumerate all
> that is expected.
> 

Thanks!

Stefan

Attachment: signature.asc
Description: PGP signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]