> -----Original Message----- > From: Linux-nvdimm [mailto:[email protected]] On Behalf Of > Brian Stark > Sent: Wednesday, September 20, 2017 11:11 AM > To: Dan Williams <[email protected]> > Cc: Raghu Kulkarni <[email protected]>; [email protected] > Subject: Re: Access to NVDIMM JEDEC registers > > Thanks for the response Dan, > > As a developer of NVDIMMs we interface to our controller using the SMBUS > interface, which is part of the JEDEC standard. In the past we have always > tested and accessed out NVDIMMs by directly manipulating the SMBUS > controller defined in the chipsets. As you may be aware this was never a > very good solution as there is an inherent synchronization problem with any > other actors that may require SMBUS access, but it was the only method > available. The solution above was good enough for testing hardware, but is > a security risk when deploying in an end user environment, not to mention > the multiple corner cases opened up trying to synchronize SMBUS access with > TSOD or the BMC. > > The DSM interface provides functions 27 and 28 (I2C Read and Write > respectively) . Most of the other functions provide the required > functionality for NVDIMMs and is almost a one to one mapping of our own API > using the method mentioned above.
Don't expect those DSMs to be available outside of debug modes. They're too dangerous for the reasons you describe: * collisions with other entities trying to use the SMBus controllers (CLTT/TSOD, BMICs, SMI handlers, etc.) * lack of higher-level mutual exclusion. JEDEC BAEBI register accesses require performing several I2C transactions without interruption. For example, the OPEN_PAGE register controls what registers are actually being accessed. Some registers are in pairs that must be read and written together to have coherent meaning. * lack of security. This would let the caller do things like change the arming, trigger a restore, download new firmware, inject errors, etc. We've discussed defining an ACPI method that software could call to arbitrate for ownership of the SMBus controller (and give it back). This would facilitate OS-based online firmware download tools, for example. One stumbling block is error handling; what if some entity wins control but doesn't give it back? There's no way to cleanly kick it off, prevent it from touching the SMBus controller registers if it does wake up, and clean up whatever transactions it had in progress. Another problem is not all the SMBus controller capabilities are necessarily supported by a system. Although software could program it to run at 1 MHz, signal integrity might only be good for 100 kHz or 400 kHz. Only system firmware knows those restrictions. Functionality-based DSMs are much safer and let system-provided code (the ACPI machine language code executed in the OS context, system firmware executed in SMM context, and system firmware executed during the next boot) figure out how to implement the request. --- Robert Elliott, HPE Persistent Memory _______________________________________________ Linux-nvdimm mailing list [email protected] https://lists.01.org/mailman/listinfo/linux-nvdimm
