1. 28 6月, 2016 1 次提交
  2. 06 5月, 2016 1 次提交
  3. 29 4月, 2016 1 次提交
    • D
      nfit, libnvdimm: clarify "commands" vs "_DSMs" · e3654eca
      Dan Williams 提交于
      Clarify the distinction between "commands", the ioctls userspace calls
      to request the kernel take some action on a given dimm device, and
      "_DSMs", the actual function numbers used in the firmware interface to
      the DIMM.  _DSMs are ACPI specific whereas commands are Linux kernel
      generic.
      
      This is in preparation for breaking the 1:1 implicit relationship
      between the kernel ioctl number space and the firmware specific function
      numbers.
      
      Cc: Jerry Hoemann <jerry.hoemann@hpe.com>
      Cc: Christoph Hellwig <hch@infradead.org>
      Signed-off-by: NDan Williams <dan.j.williams@intel.com>
      e3654eca
  4. 12 4月, 2016 1 次提交
  5. 06 3月, 2016 6 次提交
  6. 20 2月, 2016 1 次提交
  7. 10 1月, 2016 1 次提交
  8. 01 12月, 2015 1 次提交
    • L
      nfit: Adjust for different _FIT and NFIT headers · 6b577c9d
      Linda Knippers 提交于
      When support for _FIT was added, the code presumed that the data
      returned by the _FIT method is identical to the NFIT table, which
      starts with an acpi_table_header.  However, the _FIT is defined
      to return a data in the format of a series of NFIT type structure
      entries and as a method, has an acpi_object header rather tahn
      an acpi_table_header.
      
      To address the differences, explicitly save the acpi_table_header
      from the NFIT, since it is accessible through /sys, and change
      the nfit pointer in the acpi_desc structure to point to the
      table entries rather than the headers.
      
      Reported-by: Jeff Moyer (jmoyer@redhat.com>
      Signed-off-by: NLinda Knippers <linda.knippers@hpe.com>
      Acked-by: NVishal Verma <vishal.l.verma@intel.com>
      [vishal: fix up unit test for new header assumptions]
      Signed-off-by: NDan Williams <dan.j.williams@intel.com>
      6b577c9d
  9. 13 11月, 2015 1 次提交
  10. 03 11月, 2015 1 次提交
    • V
      acpi: nfit: Add support for hot-add · 20985164
      Vishal Verma 提交于
      Add a .notify callback to the acpi_nfit_driver that gets called on a
      hotplug event. From this, evaluate the _FIT ACPI method which returns
      the updated NFIT with handles for the hot-plugged NVDIMM.
      
      Iterate over the new NFIT, and add any new tables found, and
      register/enable the corresponding regions.
      
      In the nfit test framework, after normal initialization, update the NFIT
      with a new hot-plugged NVDIMM, and directly call into the driver to
      update its view of the available regions.
      
      Cc: Dan Williams <dan.j.williams@intel.com>
      Cc: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
      Cc: Toshi Kani <toshi.kani@hpe.com>
      Cc: Elliott, Robert <elliott@hpe.com>
      Cc: Jeff Moyer <jmoyer@redhat.com>
      Cc: <linux-acpi@vger.kernel.org>
      Cc: <linux-nvdimm@lists.01.org>
      Signed-off-by: NVishal Verma <vishal.l.verma@intel.com>
      Signed-off-by: NDan Williams <dan.j.williams@intel.com>
      20985164
  11. 28 8月, 2015 1 次提交
    • R
      nd_blk: change aperture mapping from WC to WB · 67a3e8fe
      Ross Zwisler 提交于
      This should result in a pretty sizeable performance gain for reads.  For
      rough comparison I did some simple read testing using PMEM to compare
      reads of write combining (WC) mappings vs write-back (WB).  This was
      done on a random lab machine.
      
      PMEM reads from a write combining mapping:
      	# dd of=/dev/null if=/dev/pmem0 bs=4096 count=100000
      	100000+0 records in
      	100000+0 records out
      	409600000 bytes (410 MB) copied, 9.2855 s, 44.1 MB/s
      
      PMEM reads from a write-back mapping:
      	# dd of=/dev/null if=/dev/pmem0 bs=4096 count=1000000
      	1000000+0 records in
      	1000000+0 records out
      	4096000000 bytes (4.1 GB) copied, 3.44034 s, 1.2 GB/s
      
      To be able to safely support a write-back aperture I needed to add
      support for the "read flush" _DSM flag, as outlined in the DSM spec:
      
      http://pmem.io/documents/NVDIMM_DSM_Interface_Example.pdf
      
      This flag tells the ND BLK driver that it needs to flush the cache lines
      associated with the aperture after the aperture is moved but before any
      new data is read.  This ensures that any stale cache lines from the
      previous contents of the aperture will be discarded from the processor
      cache, and the new data will be read properly from the DIMM.  We know
      that the cache lines are clean and will be discarded without any
      writeback because either a) the previous aperture operation was a read,
      and we never modified the contents of the aperture, or b) the previous
      aperture operation was a write and we must have written back the dirtied
      contents of the aperture to the DIMM before the I/O was completed.
      
      In order to add support for the "read flush" flag I needed to add a
      generic routine to invalidate cache lines, mmio_flush_range().  This is
      protected by the ARCH_HAS_MMIO_FLUSH Kconfig variable, and is currently
      only supported on x86.
      Signed-off-by: NRoss Zwisler <ross.zwisler@linux.intel.com>
      Signed-off-by: NDan Williams <dan.j.williams@intel.com>
      67a3e8fe
  12. 28 7月, 2015 1 次提交
  13. 11 7月, 2015 2 次提交
  14. 26 6月, 2015 2 次提交
    • D
      libnvdimm, nfit: handle unarmed dimms, mark namespaces read-only · 58138820
      Dan Williams 提交于
      Upon detection of an unarmed dimm in a region, arrange for descendant
      BTT, PMEM, or BLK instances to be read-only.  A dimm is primarily marked
      "unarmed" via flags passed by platform firmware (NFIT).
      
      The flags in the NFIT memory device sub-structure indicate the state of
      the data on the nvdimm relative to its energy source or last "flush to
      persistence".  For the most part there is nothing the driver can do but
      advertise the state of these flags in sysfs and emit a message if
      firmware indicates that the contents of the device may be corrupted.
      However, for the case of ACPI_NFIT_MEM_ARMED, the driver can arrange for
      the block devices incorporating that nvdimm to be marked read-only.
      This is a safe default as the data is still available and new writes are
      held off until the administrator either forces read-write mode, or the
      energy source becomes armed.
      
      A 'read_only' attribute is added to REGION devices to allow for
      overriding the default read-only policy of all descendant block devices.
      Signed-off-by: NDan Williams <dan.j.williams@intel.com>
      58138820
    • D
      tools/testing/nvdimm: libnvdimm unit test infrastructure · 6bc75619
      Dan Williams 提交于
      'libnvdimm' is the first driver sub-system in the kernel to implement
      mocking for unit test coverage.  The nfit_test module gets built as an
      external module and arranges for external module replacements of nfit,
      libnvdimm, nd_pmem, and nd_blk.  These replacements use the linker
      --wrap option to redirect calls to ioremap() + request_mem_region() to
      custom defined unit test resources.  The end result is a fully
      functional nvdimm_bus, as far as userspace is concerned, but with the
      capability to perform otherwise destructive tests on emulated resources.
      
      Q: Why not use QEMU for this emulation?
      QEMU is not suitable for unit testing.  QEMU's role is to faithfully
      emulate the platform.  A unit test's role is to unfaithfully implement
      the platform with the goal of triggering bugs in the corners of the
      sub-system implementation.  As bugs are discovered in platforms, or the
      sub-system itself, the unit tests are extended to backstop a fix with a
      reproducer unit test.
      
      Another problem with QEMU is that it would require coordination of 3
      software projects instead of 2 (kernel + libndctl [1]) to maintain and
      execute the tests.  The chances for bit rot and the difficulty of
      getting the tests running goes up non-linearly the more components
      involved.
      
      
      Q: Why submit this to the kernel tree instead of external modules in
         libndctl?
      Simple, to alleviate the same risk that out-of-tree external modules
      face.  Updates to drivers/nvdimm/ can be immediately evaluated to see if
      they have any impact on tools/testing/nvdimm/.
      
      
      Q: What are the negative implications of merging this?
      It is a unique maintenance burden because the purpose of mocking an
      interface to enable a unit test is to purposefully short circuit the
      semantics of a routine to enable testing.  For example
      __wrap_ioremap_cache() fakes the pmem driver into "ioremap()'ing" a test
      resource buffer allocated by dma_alloc_coherent().  The future
      maintenance burden hits when someone changes the semantics of
      ioremap_cache() and wonders what the implications are for the unit test.
      
      [1]: https://github.com/pmem/ndctl
      
      Cc: <linux-acpi@vger.kernel.org>
      Cc: Lv Zheng <lv.zheng@intel.com>
      Cc: Robert Moore <robert.moore@intel.com>
      Cc: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
      Cc: Christoph Hellwig <hch@lst.de>
      Signed-off-by: NDan Williams <dan.j.williams@intel.com>
      6bc75619