| Message ID | 1440024484-26152-1-git-send-email-ross.zwisler@linux.intel.com (mailing list archive) |
|---|---|
| State | Accepted |
| Commit | 67a3e8fe9015 |
| Headers | show |
On Wed, Aug 19, 2015 at 3:48 PM, Ross Zwisler <ross.zwisler@linux.intel.com> wrote: > 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. > > By supporting the "read flush" flag we can also change the ND BLK > aperture mapping from write-combining to write-back via memremap(). > > 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: Ross Zwisler <ross.zwisler@linux.intel.com> > Cc: Dan Williams <dan.j.williams@intel.com> [..] > diff --git a/drivers/acpi/nfit.c b/drivers/acpi/nfit.c > index 7c2638f..56fff01 100644 > --- a/drivers/acpi/nfit.c > +++ b/drivers/acpi/nfit.c [..] > static int acpi_nfit_blk_single_io(struct nfit_blk *nfit_blk, > @@ -1078,11 +1078,16 @@ static int acpi_nfit_blk_single_io(struct nfit_blk *nfit_blk, > } > > if (rw) > - memcpy_to_pmem(mmio->aperture + offset, > + memcpy_to_pmem(mmio->addr.aperture + offset, > iobuf + copied, c); > - else > + else { > + if (nfit_blk->dimm_flags & ND_BLK_READ_FLUSH) > + mmio_flush_range((void __force *) > + mmio->addr.aperture + offset, c); > + > memcpy_from_pmem(iobuf + copied, > - mmio->aperture + offset, c); > + mmio->addr.aperture + offset, c); > + } Why is the flush inside the "while (len)" loop? I think it should be done immediately after the call to write_blk_ctl() since that is the point at which the aperture becomes invalidated, and not prior to each read within a given aperture position. Taking it a bit further, we may be writing the same address into the control register as was there previously so we wouldn't need to flush in that case.
On Wed, Aug 19, 2015 at 11:48:04PM +0100, Ross Zwisler wrote: > 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. Is this operation expected to be implemented as a destructive invalidation (i.e. discarding any dirty lines from the cache) or also a writeback of any dirtylines as part of the invalidation? If its the former, we might want to give it a scarier name to ensure that it doesn't grow users outside of NVDIMM scenarios, since "flush" is used elsewhere for things like flush_dcache_page. Will
On Thu, 2015-08-20 at 11:21 +0100, Will Deacon wrote: > On Wed, Aug 19, 2015 at 11:48:04PM +0100, Ross Zwisler wrote: > > 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. > > Is this operation expected to be implemented as a destructive invalidation > (i.e. discarding any dirty lines from the cache) or also a writeback of any > dirtylines as part of the invalidation? > > If its the former, we might want to give it a scarier name to ensure that > it doesn't grow users outside of NVDIMM scenarios, since "flush" is used > elsewhere for things like flush_dcache_page. It is the latter - there will be a writeback of any dirty lines as part of the invalidation. The real thing I'm looking for is a forced invalidation (including writeback, if needed), even on architectures that are cache coherent. This is useful when the device can change the data at that memory location, but not as part of a normal DMA operation that would keep the cache coherent.
On Wed, 2015-08-19 at 16:06 -0700, Dan Williams wrote: > On Wed, Aug 19, 2015 at 3:48 PM, Ross Zwisler > <ross.zwisler@linux.intel.com> wrote: > > 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. > > > > By supporting the "read flush" flag we can also change the ND BLK > > aperture mapping from write-combining to write-back via memremap(). > > > > 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: Ross Zwisler <ross.zwisler@linux.intel.com> > > Cc: Dan Williams <dan.j.williams@intel.com> > [..] > > diff --git a/drivers/acpi/nfit.c b/drivers/acpi/nfit.c > > index 7c2638f..56fff01 100644 > > --- a/drivers/acpi/nfit.c > > +++ b/drivers/acpi/nfit.c > [..] > > static int acpi_nfit_blk_single_io(struct nfit_blk *nfit_blk, > > @@ -1078,11 +1078,16 @@ static int acpi_nfit_blk_single_io(struct nfit_blk *nfit_blk, > > } > > > > if (rw) > > - memcpy_to_pmem(mmio->aperture + offset, > > + memcpy_to_pmem(mmio->addr.aperture + offset, > > iobuf + copied, c); > > - else > > + else { > > + if (nfit_blk->dimm_flags & ND_BLK_READ_FLUSH) > > + mmio_flush_range((void __force *) > > + mmio->addr.aperture + offset, c); > > + > > memcpy_from_pmem(iobuf + copied, > > - mmio->aperture + offset, c); > > + mmio->addr.aperture + offset, c); > > + } > > Why is the flush inside the "while (len)" loop? I think it should be > done immediately after the call to write_blk_ctl() since that is the > point at which the aperture becomes invalidated, and not prior to each > read within a given aperture position. Taking it a bit further, we > may be writing the same address into the control register as was there > previously so we wouldn't need to flush in that case. The reason I was doing it in the "while (len)" loop is that you have to walk through the interleave tables, reading each segment until you have read 'len' bytes. If we were to invalidate right after the write_blk_ctl(), we would essentially have to re-create the "while (len)" loop, hop through all the segments doing the invalidation, then run through the segments again doing the actual I/O. It seemed a lot cleaner to just run through the segments once, invalidating and reading each segment individually. The bad news about the current approach is that we end up doing a bunch of extra mb() fencing, twice per segment via clflush_cache_range(). The other option would be to do the double pass, but on the first pass to just do the flushing without fencing, then fence everything, then do the reads. I don't have a good feel for how much overhead all this extra fencing will be vs the cost of traversing the segments twice. The code is certainly simpler with the way its implemented now. If you feel that the extra fencing is too expensive I'll implement it as a double-pass. Otherwise we may want to wait for performance data to justify the change. Regarding skipping the flush if the control register is unchanged - sure, that seems like a good idea.
On Thu, Aug 20, 2015 at 9:44 AM, Ross Zwisler <ross.zwisler@linux.intel.com> wrote: > On Wed, 2015-08-19 at 16:06 -0700, Dan Williams wrote: >> On Wed, Aug 19, 2015 at 3:48 PM, Ross Zwisler >> <ross.zwisler@linux.intel.com> wrote: >> > 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. >> > >> > By supporting the "read flush" flag we can also change the ND BLK >> > aperture mapping from write-combining to write-back via memremap(). >> > >> > 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: Ross Zwisler <ross.zwisler@linux.intel.com> >> > Cc: Dan Williams <dan.j.williams@intel.com> >> [..] >> > diff --git a/drivers/acpi/nfit.c b/drivers/acpi/nfit.c >> > index 7c2638f..56fff01 100644 >> > --- a/drivers/acpi/nfit.c >> > +++ b/drivers/acpi/nfit.c >> [..] >> > static int acpi_nfit_blk_single_io(struct nfit_blk *nfit_blk, >> > @@ -1078,11 +1078,16 @@ static int acpi_nfit_blk_single_io(struct nfit_blk *nfit_blk, >> > } >> > >> > if (rw) >> > - memcpy_to_pmem(mmio->aperture + offset, >> > + memcpy_to_pmem(mmio->addr.aperture + offset, >> > iobuf + copied, c); >> > - else >> > + else { >> > + if (nfit_blk->dimm_flags & ND_BLK_READ_FLUSH) >> > + mmio_flush_range((void __force *) >> > + mmio->addr.aperture + offset, c); >> > + >> > memcpy_from_pmem(iobuf + copied, >> > - mmio->aperture + offset, c); >> > + mmio->addr.aperture + offset, c); >> > + } >> >> Why is the flush inside the "while (len)" loop? I think it should be >> done immediately after the call to write_blk_ctl() since that is the >> point at which the aperture becomes invalidated, and not prior to each >> read within a given aperture position. Taking it a bit further, we >> may be writing the same address into the control register as was there >> previously so we wouldn't need to flush in that case. > > The reason I was doing it in the "while (len)" loop is that you have to walk > through the interleave tables, reading each segment until you have read 'len' > bytes. If we were to invalidate right after the write_blk_ctl(), we would > essentially have to re-create the "while (len)" loop, hop through all the > segments doing the invalidation, then run through the segments again doing the > actual I/O. > > It seemed a lot cleaner to just run through the segments once, invalidating > and reading each segment individually. I agree it's cleaner if it is considering the de-interleave, but why consider interleave at all? In other words just flush the entire aperture unconditionally. Regardless of whether it reads all of the aperture it is indeed invalid because the aperture has moved. I'm not seeing the benefit of being careful to let stale data stay in the cache a bit longer.
On Thu, 2015-08-20 at 10:59 -0700, Dan Williams wrote: > On Thu, Aug 20, 2015 at 9:44 AM, Ross Zwisler > <ross.zwisler@linux.intel.com> wrote: > > On Wed, 2015-08-19 at 16:06 -0700, Dan Williams wrote: > >> On Wed, Aug 19, 2015 at 3:48 PM, Ross Zwisler > >> <ross.zwisler@linux.intel.com> wrote: > >> > 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. > >> > > >> > By supporting the "read flush" flag we can also change the ND BLK > >> > aperture mapping from write-combining to write-back via memremap(). > >> > > >> > 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: Ross Zwisler <ross.zwisler@linux.intel.com> > >> > Cc: Dan Williams <dan.j.williams@intel.com> > >> [..] > >> > diff --git a/drivers/acpi/nfit.c b/drivers/acpi/nfit.c > >> > index 7c2638f..56fff01 100644 > >> > --- a/drivers/acpi/nfit.c > >> > +++ b/drivers/acpi/nfit.c > >> [..] > >> > static int acpi_nfit_blk_single_io(struct nfit_blk *nfit_blk, > >> > @@ -1078,11 +1078,16 @@ static int acpi_nfit_blk_single_io(struct nfit_blk *nfit_blk, > >> > } > >> > > >> > if (rw) > >> > - memcpy_to_pmem(mmio->aperture + offset, > >> > + memcpy_to_pmem(mmio->addr.aperture + offset, > >> > iobuf + copied, c); > >> > - else > >> > + else { > >> > + if (nfit_blk->dimm_flags & ND_BLK_READ_FLUSH) > >> > + mmio_flush_range((void __force *) > >> > + mmio->addr.aperture + offset, c); > >> > + > >> > memcpy_from_pmem(iobuf + copied, > >> > - mmio->aperture + offset, c); > >> > + mmio->addr.aperture + offset, c); > >> > + } > >> > >> Why is the flush inside the "while (len)" loop? I think it should be > >> done immediately after the call to write_blk_ctl() since that is the > >> point at which the aperture becomes invalidated, and not prior to each > >> read within a given aperture position. Taking it a bit further, we > >> may be writing the same address into the control register as was there > >> previously so we wouldn't need to flush in that case. > > > > The reason I was doing it in the "while (len)" loop is that you have to walk > > through the interleave tables, reading each segment until you have read 'len' > > bytes. If we were to invalidate right after the write_blk_ctl(), we would > > essentially have to re-create the "while (len)" loop, hop through all the > > segments doing the invalidation, then run through the segments again doing the > > actual I/O. > > > > It seemed a lot cleaner to just run through the segments once, invalidating > > and reading each segment individually. > > I agree it's cleaner if it is considering the de-interleave, but why > consider interleave at all? In other words just flush the entire > aperture unconditionally. Regardless of whether it reads all of the > aperture it is indeed invalid because the aperture has moved. I'm not > seeing the benefit of being careful to let stale data stay in the > cache a bit longer. Ah, I think we're getting confused about the deinterleave part. The aperture is a set of contiguous addresses from the perspective of the DIMM, but when it's interleaved by the iMC it becomes a bunch of segments that are not contiguous in the virtual address space of the kernel. Meaning, say you have an 8k aperture that is interleaved with one other DIMM on a 256 byte granularity - this means that in SPA space you'll end up with a big mesh of 256 byte chunks, half of which belong to you and half which don't: SPA space: +--------------------+ |256 bytes (ours) | +--------------------+ |256 bytes (not ours)| +--------------------+ |256 bytes (ours) | +--------------------+ |256 bytes (not ours)| +--------------------+ ... To be able to flush the entire aperture unconditionally, we have to walk through all the segments that belong to use and flush each one of them. I don't think we want to blindly flush the entire interleaved space because a) the other chunks are some other DIMMs' apertures, and b) we'd be flushing 2x or more (depending on how many DIMMs are interleaved) the space we need, one cache line at a time. I really think we do need to walk through the chunks and to targeted flushing - the only question is whether we do a single pass and live with extra intermediate memory barriers, or whether we do 2 passes and have a memory barrier in between.
On Thu, Aug 20, 2015 at 11:17 AM, Ross Zwisler <ross.zwisler@linux.intel.com> wrote: > On Thu, 2015-08-20 at 10:59 -0700, Dan Williams wrote: [..] > Ah, I think we're getting confused about the deinterleave part. > > The aperture is a set of contiguous addresses from the perspective of the > DIMM, but when it's interleaved by the iMC it becomes a bunch of segments that > are not contiguous in the virtual address space of the kernel. > > Meaning, say you have an 8k aperture that is interleaved with one other DIMM > on a 256 byte granularity - this means that in SPA space you'll end up with a > big mesh of 256 byte chunks, half of which belong to you and half which don't: > > SPA space: > +--------------------+ > |256 bytes (ours) | > +--------------------+ > |256 bytes (not ours)| > +--------------------+ > |256 bytes (ours) | > +--------------------+ > |256 bytes (not ours)| > +--------------------+ > ... > > To be able to flush the entire aperture unconditionally, we have to walk > through all the segments that belong to use and flush each one of them. I > don't think we want to blindly flush the entire interleaved space because a) > the other chunks are some other DIMMs' apertures, and b) we'd be flushing 2x > or more (depending on how many DIMMs are interleaved) the space we need, one > cache line at a time. I am indeed proposing flushing other DIMMs because those ranges are invalidated by the aperture moving. This is based on the assumption that the flushing is cheaper in the case when no dirty-lines are found. The performance gains of doing piecemeal flushes seems not worth the complexity.
On Thu, 2015-08-20 at 11:26 -0700, Dan Williams wrote: > On Thu, Aug 20, 2015 at 11:17 AM, Ross Zwisler > <ross.zwisler@linux.intel.com> wrote: > > On Thu, 2015-08-20 at 10:59 -0700, Dan Williams wrote: > [..] > > Ah, I think we're getting confused about the deinterleave part. > > > > The aperture is a set of contiguous addresses from the perspective of the > > DIMM, but when it's interleaved by the iMC it becomes a bunch of segments that > > are not contiguous in the virtual address space of the kernel. > > > > Meaning, say you have an 8k aperture that is interleaved with one other DIMM > > on a 256 byte granularity - this means that in SPA space you'll end up with a > > big mesh of 256 byte chunks, half of which belong to you and half which don't: > > > > SPA space: > > +--------------------+ > > |256 bytes (ours) | > > +--------------------+ > > |256 bytes (not ours)| > > +--------------------+ > > |256 bytes (ours) | > > +--------------------+ > > |256 bytes (not ours)| > > +--------------------+ > > ... > > > > To be able to flush the entire aperture unconditionally, we have to walk > > through all the segments that belong to use and flush each one of them. I > > don't think we want to blindly flush the entire interleaved space because a) > > the other chunks are some other DIMMs' apertures, and b) we'd be flushing 2x > > or more (depending on how many DIMMs are interleaved) the space we need, one > > cache line at a time. > > I am indeed proposing flushing other DIMMs because those ranges are > invalidated by the aperture moving. This is based on the assumption > that the flushing is cheaper in the case when no dirty-lines are > found. The performance gains of doing piecemeal flushes seems not > worth the complexity. Why are the segments belonging to other apertures invalidated because we have moved our aperture? They are all independent cache lines (segments must be a multiple of the cache line size), and the other apertures might be in the middle of some other I/O operation on some other CPU that we know nothing about.
On Thu, Aug 20, 2015 at 12:00 PM, Ross Zwisler <ross.zwisler@linux.intel.com> wrote: > On Thu, 2015-08-20 at 11:26 -0700, Dan Williams wrote: >> On Thu, Aug 20, 2015 at 11:17 AM, Ross Zwisler >> <ross.zwisler@linux.intel.com> wrote: >> > On Thu, 2015-08-20 at 10:59 -0700, Dan Williams wrote: >> [..] >> > Ah, I think we're getting confused about the deinterleave part. >> > >> > The aperture is a set of contiguous addresses from the perspective of the >> > DIMM, but when it's interleaved by the iMC it becomes a bunch of segments that >> > are not contiguous in the virtual address space of the kernel. >> > >> > Meaning, say you have an 8k aperture that is interleaved with one other DIMM >> > on a 256 byte granularity - this means that in SPA space you'll end up with a >> > big mesh of 256 byte chunks, half of which belong to you and half which don't: >> > >> > SPA space: >> > +--------------------+ >> > |256 bytes (ours) | >> > +--------------------+ >> > |256 bytes (not ours)| >> > +--------------------+ >> > |256 bytes (ours) | >> > +--------------------+ >> > |256 bytes (not ours)| >> > +--------------------+ >> > ... >> > >> > To be able to flush the entire aperture unconditionally, we have to walk >> > through all the segments that belong to use and flush each one of them. I >> > don't think we want to blindly flush the entire interleaved space because a) >> > the other chunks are some other DIMMs' apertures, and b) we'd be flushing 2x >> > or more (depending on how many DIMMs are interleaved) the space we need, one >> > cache line at a time. >> >> I am indeed proposing flushing other DIMMs because those ranges are >> invalidated by the aperture moving. This is based on the assumption >> that the flushing is cheaper in the case when no dirty-lines are >> found. The performance gains of doing piecemeal flushes seems not >> worth the complexity. > > Why are the segments belonging to other apertures invalidated because we have > moved our aperture? They are all independent cache lines (segments must be a > multiple of the cache line size), and the other apertures might be in the > middle of some other I/O operation on some other CPU that we know nothing > about. > Ah, ok the other DIMM data in the aperture should never be consumed and does not need to be invalidated. I'm straightened out on that aspect. With regards to the fencing, since we already take care to flush writes we don't need to fence at all for the flush, right? All we care about is that reads see valid data.
On Thu, 2015-08-20 at 13:27 -0700, Dan Williams wrote: [...] > With regards to the fencing, since we already take care to flush > writes we don't need to fence at all for the flush, right? All we > care about is that reads see valid data. We were careful to flush writes, but we could still have (now stale) data in the cache either due to a previous read or because of prefetching. So we need to flush, and we need to fence to make sure that our flushing stays correctly ordered with respect to our reads. So, to recap, I think are options are: a) loop through aperture segments, flushing each without any fencing mb() to order all the flushes loop through aperture segments, doing the reads b) loop through aperture segments flushing segment with mb() fencing read the new data for this segment from the DIMM Option b) is what is already implemented and is cleaner, but option a) has the benefit of having many fewer fences.
On Thu, Aug 20, 2015 at 2:15 PM, Ross Zwisler <ross.zwisler@linux.intel.com> wrote: > On Thu, 2015-08-20 at 13:27 -0700, Dan Williams wrote: > [...] >> With regards to the fencing, since we already take care to flush >> writes we don't need to fence at all for the flush, right? All we >> care about is that reads see valid data. > > We were careful to flush writes, but we could still have (now stale) data in > the cache either due to a previous read or because of prefetching. So we > need to flush, and we need to fence to make sure that our flushing stays > correctly ordered with respect to our reads. Hmm, so clflushopt does not guarantee that a read in program order after a clflushopt sees the invalidate? It seems like we're not getting any advantage of using clfushopt vs clflush. Let's go with this for now, but anything further should be guided by performance numbers.
diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig index 76c6115..03ab612 100644 --- a/arch/x86/Kconfig +++ b/arch/x86/Kconfig @@ -28,6 +28,7 @@ config X86 select ARCH_HAS_FAST_MULTIPLIER select ARCH_HAS_GCOV_PROFILE_ALL select ARCH_HAS_PMEM_API + select ARCH_HAS_MMIO_FLUSH select ARCH_HAS_SG_CHAIN select ARCH_HAVE_NMI_SAFE_CMPXCHG select ARCH_MIGHT_HAVE_ACPI_PDC if ACPI diff --git a/arch/x86/include/asm/cacheflush.h b/arch/x86/include/asm/cacheflush.h index 471418a..e63aa38 100644 --- a/arch/x86/include/asm/cacheflush.h +++ b/arch/x86/include/asm/cacheflush.h @@ -89,6 +89,8 @@ int set_pages_rw(struct page *page, int numpages); void clflush_cache_range(void *addr, unsigned int size); +#define mmio_flush_range(addr, size) clflush_cache_range(addr, size) + #ifdef CONFIG_DEBUG_RODATA void mark_rodata_ro(void); extern const int rodata_test_data; diff --git a/arch/x86/include/asm/io.h b/arch/x86/include/asm/io.h index d241fbd..83ec9b1 100644 --- a/arch/x86/include/asm/io.h +++ b/arch/x86/include/asm/io.h @@ -248,8 +248,6 @@ static inline void flush_write_buffers(void) #endif } -#define ARCH_MEMREMAP_PMEM MEMREMAP_WB - #endif /* __KERNEL__ */ extern void native_io_delay(void); diff --git a/arch/x86/include/asm/pmem.h b/arch/x86/include/asm/pmem.h index a3a0df6..bb026c5 100644 --- a/arch/x86/include/asm/pmem.h +++ b/arch/x86/include/asm/pmem.h @@ -18,6 +18,8 @@ #include <asm/cpufeature.h> #include <asm/special_insns.h> +#define ARCH_MEMREMAP_PMEM MEMREMAP_WB + #ifdef CONFIG_ARCH_HAS_PMEM_API /** * arch_memcpy_to_pmem - copy data to persistent memory diff --git a/drivers/acpi/Kconfig b/drivers/acpi/Kconfig index 114cf48..4baeb85 100644 --- a/drivers/acpi/Kconfig +++ b/drivers/acpi/Kconfig @@ -410,6 +410,7 @@ config ACPI_NFIT tristate "ACPI NVDIMM Firmware Interface Table (NFIT)" depends on PHYS_ADDR_T_64BIT depends on BLK_DEV + depends on ARCH_HAS_MMIO_FLUSH select LIBNVDIMM help Infrastructure to probe ACPI 6 compliant platforms for diff --git a/drivers/acpi/nfit.c b/drivers/acpi/nfit.c index 7c2638f..56fff01 100644 --- a/drivers/acpi/nfit.c +++ b/drivers/acpi/nfit.c @@ -1017,7 +1017,7 @@ static u64 read_blk_stat(struct nfit_blk *nfit_blk, unsigned int bw) if (mmio->num_lines) offset = to_interleave_offset(offset, mmio); - return readq(mmio->base + offset); + return readq(mmio->addr.base + offset); } static void write_blk_ctl(struct nfit_blk *nfit_blk, unsigned int bw, @@ -1042,11 +1042,11 @@ static void write_blk_ctl(struct nfit_blk *nfit_blk, unsigned int bw, if (mmio->num_lines) offset = to_interleave_offset(offset, mmio); - writeq(cmd, mmio->base + offset); + writeq(cmd, mmio->addr.base + offset); wmb_blk(nfit_blk); if (nfit_blk->dimm_flags & ND_BLK_DCR_LATCH) - readq(mmio->base + offset); + readq(mmio->addr.base + offset); } static int acpi_nfit_blk_single_io(struct nfit_blk *nfit_blk, @@ -1078,11 +1078,16 @@ static int acpi_nfit_blk_single_io(struct nfit_blk *nfit_blk, } if (rw) - memcpy_to_pmem(mmio->aperture + offset, + memcpy_to_pmem(mmio->addr.aperture + offset, iobuf + copied, c); - else + else { + if (nfit_blk->dimm_flags & ND_BLK_READ_FLUSH) + mmio_flush_range((void __force *) + mmio->addr.aperture + offset, c); + memcpy_from_pmem(iobuf + copied, - mmio->aperture + offset, c); + mmio->addr.aperture + offset, c); + } copied += c; len -= c; @@ -1129,7 +1134,10 @@ static void nfit_spa_mapping_release(struct kref *kref) WARN_ON(!mutex_is_locked(&acpi_desc->spa_map_mutex)); dev_dbg(acpi_desc->dev, "%s: SPA%d\n", __func__, spa->range_index); - iounmap(spa_map->iomem); + if (spa_map->type == SPA_MAP_APERTURE) + memunmap((void __force *)spa_map->addr.aperture); + else + iounmap(spa_map->addr.base); release_mem_region(spa->address, spa->length); list_del(&spa_map->list); kfree(spa_map); @@ -1175,7 +1183,7 @@ static void __iomem *__nfit_spa_map(struct acpi_nfit_desc *acpi_desc, spa_map = find_spa_mapping(acpi_desc, spa); if (spa_map) { kref_get(&spa_map->kref); - return spa_map->iomem; + return spa_map->addr.base; } spa_map = kzalloc(sizeof(*spa_map), GFP_KERNEL); @@ -1191,20 +1199,19 @@ static void __iomem *__nfit_spa_map(struct acpi_nfit_desc *acpi_desc, if (!res) goto err_mem; - if (type == SPA_MAP_APERTURE) { - /* - * TODO: memremap_pmem() support, but that requires cache - * flushing when the aperture is moved. - */ - spa_map->iomem = ioremap_wc(start, n); - } else - spa_map->iomem = ioremap_nocache(start, n); + spa_map->type = type; + if (type == SPA_MAP_APERTURE) + spa_map->addr.aperture = (void __pmem *)memremap(start, n, + ARCH_MEMREMAP_PMEM); + else + spa_map->addr.base = ioremap_nocache(start, n); + - if (!spa_map->iomem) + if (!spa_map->addr.base) goto err_map; list_add_tail(&spa_map->list, &acpi_desc->spa_maps); - return spa_map->iomem; + return spa_map->addr.base; err_map: release_mem_region(start, n); @@ -1267,7 +1274,7 @@ static int acpi_nfit_blk_get_flags(struct nvdimm_bus_descriptor *nd_desc, nfit_blk->dimm_flags = flags.flags; else if (rc == -ENOTTY) { /* fall back to a conservative default */ - nfit_blk->dimm_flags = ND_BLK_DCR_LATCH; + nfit_blk->dimm_flags = ND_BLK_DCR_LATCH | ND_BLK_READ_FLUSH; rc = 0; } else rc = -ENXIO; @@ -1307,9 +1314,9 @@ static int acpi_nfit_blk_region_enable(struct nvdimm_bus *nvdimm_bus, /* map block aperture memory */ nfit_blk->bdw_offset = nfit_mem->bdw->offset; mmio = &nfit_blk->mmio[BDW]; - mmio->base = nfit_spa_map(acpi_desc, nfit_mem->spa_bdw, + mmio->addr.base = nfit_spa_map(acpi_desc, nfit_mem->spa_bdw, SPA_MAP_APERTURE); - if (!mmio->base) { + if (!mmio->addr.base) { dev_dbg(dev, "%s: %s failed to map bdw\n", __func__, nvdimm_name(nvdimm)); return -ENOMEM; @@ -1330,9 +1337,9 @@ static int acpi_nfit_blk_region_enable(struct nvdimm_bus *nvdimm_bus, nfit_blk->cmd_offset = nfit_mem->dcr->command_offset; nfit_blk->stat_offset = nfit_mem->dcr->status_offset; mmio = &nfit_blk->mmio[DCR]; - mmio->base = nfit_spa_map(acpi_desc, nfit_mem->spa_dcr, + mmio->addr.base = nfit_spa_map(acpi_desc, nfit_mem->spa_dcr, SPA_MAP_CONTROL); - if (!mmio->base) { + if (!mmio->addr.base) { dev_dbg(dev, "%s: %s failed to map dcr\n", __func__, nvdimm_name(nvdimm)); return -ENOMEM; @@ -1399,7 +1406,7 @@ static void acpi_nfit_blk_region_disable(struct nvdimm_bus *nvdimm_bus, for (i = 0; i < 2; i++) { struct nfit_blk_mmio *mmio = &nfit_blk->mmio[i]; - if (mmio->base) + if (mmio->addr.base) nfit_spa_unmap(acpi_desc, mmio->spa); } nd_blk_region_set_provider_data(ndbr, NULL); diff --git a/drivers/acpi/nfit.h b/drivers/acpi/nfit.h index f2c2bb7..7e74015 100644 --- a/drivers/acpi/nfit.h +++ b/drivers/acpi/nfit.h @@ -41,6 +41,7 @@ enum nfit_uuids { }; enum { + ND_BLK_READ_FLUSH = 1, ND_BLK_DCR_LATCH = 2, }; @@ -117,12 +118,16 @@ enum nd_blk_mmio_selector { DCR, }; +struct nd_blk_addr { + union { + void __iomem *base; + void __pmem *aperture; + }; +}; + struct nfit_blk { struct nfit_blk_mmio { - union { - void __iomem *base; - void __pmem *aperture; - }; + struct nd_blk_addr addr; u64 size; u64 base_offset; u32 line_size; @@ -149,7 +154,8 @@ struct nfit_spa_mapping { struct acpi_nfit_system_address *spa; struct list_head list; struct kref kref; - void __iomem *iomem; + enum spa_map_type type; + struct nd_blk_addr addr; }; static inline struct nfit_spa_mapping *to_spa_map(struct kref *kref) diff --git a/lib/Kconfig b/lib/Kconfig index 3a2ef67..a938a39 100644 --- a/lib/Kconfig +++ b/lib/Kconfig @@ -531,4 +531,7 @@ config ARCH_HAS_SG_CHAIN config ARCH_HAS_PMEM_API bool +config ARCH_HAS_MMIO_FLUSH + bool + endmenu diff --git a/tools/testing/nvdimm/Kbuild b/tools/testing/nvdimm/Kbuild index e667579..98f2881 100644 --- a/tools/testing/nvdimm/Kbuild +++ b/tools/testing/nvdimm/Kbuild @@ -1,8 +1,10 @@ ldflags-y += --wrap=ioremap_wc +ldflags-y += --wrap=memremap ldflags-y += --wrap=devm_ioremap_nocache ldflags-y += --wrap=devm_memremap ldflags-y += --wrap=ioremap_nocache ldflags-y += --wrap=iounmap +ldflags-y += --wrap=memunmap ldflags-y += --wrap=__devm_request_region ldflags-y += --wrap=__request_region ldflags-y += --wrap=__release_region diff --git a/tools/testing/nvdimm/test/iomap.c b/tools/testing/nvdimm/test/iomap.c index ff1e004..179d228 100644 --- a/tools/testing/nvdimm/test/iomap.c +++ b/tools/testing/nvdimm/test/iomap.c @@ -89,12 +89,25 @@ void *__wrap_devm_memremap(struct device *dev, resource_size_t offset, nfit_res = get_nfit_res(offset); rcu_read_unlock(); if (nfit_res) - return (void __iomem *) nfit_res->buf + offset - - nfit_res->res->start; + return nfit_res->buf + offset - nfit_res->res->start; return devm_memremap(dev, offset, size, flags); } EXPORT_SYMBOL(__wrap_devm_memremap); +void *__wrap_memremap(resource_size_t offset, size_t size, + unsigned long flags) +{ + struct nfit_test_resource *nfit_res; + + rcu_read_lock(); + nfit_res = get_nfit_res(offset); + rcu_read_unlock(); + if (nfit_res) + return nfit_res->buf + offset - nfit_res->res->start; + return memremap(offset, size, flags); +} +EXPORT_SYMBOL(__wrap_memremap); + void __iomem *__wrap_ioremap_nocache(resource_size_t offset, unsigned long size) { return __nfit_test_ioremap(offset, size, ioremap_nocache); @@ -120,6 +133,19 @@ void __wrap_iounmap(volatile void __iomem *addr) } EXPORT_SYMBOL(__wrap_iounmap); +void __wrap_memunmap(void *addr) +{ + struct nfit_test_resource *nfit_res; + + rcu_read_lock(); + nfit_res = get_nfit_res((unsigned long) addr); + rcu_read_unlock(); + if (nfit_res) + return; + return memunmap(addr); +} +EXPORT_SYMBOL(__wrap_memunmap); + static struct resource *nfit_test_request_region(struct device *dev, struct resource *parent, resource_size_t start, resource_size_t n, const char *name, int flags) diff --git a/tools/testing/nvdimm/test/nfit.c b/tools/testing/nvdimm/test/nfit.c index 28dba91..021e6f9 100644 --- a/tools/testing/nvdimm/test/nfit.c +++ b/tools/testing/nvdimm/test/nfit.c @@ -1029,9 +1029,13 @@ static int nfit_test_blk_do_io(struct nd_blk_region *ndbr, resource_size_t dpa, lane = nd_region_acquire_lane(nd_region); if (rw) - memcpy(mmio->base + dpa, iobuf, len); - else - memcpy(iobuf, mmio->base + dpa, len); + memcpy(mmio->addr.base + dpa, iobuf, len); + else { + memcpy(iobuf, mmio->addr.base + dpa, len); + + /* give us some some coverage of the mmio_flush_range() API */ + mmio_flush_range(mmio->addr.base + dpa, len); + } nd_region_release_lane(nd_region, lane); return 0;
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. By supporting the "read flush" flag we can also change the ND BLK aperture mapping from write-combining to write-back via memremap(). 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: Ross Zwisler <ross.zwisler@linux.intel.com> Cc: Dan Williams <dan.j.williams@intel.com> --- arch/x86/Kconfig | 1 + arch/x86/include/asm/cacheflush.h | 2 ++ arch/x86/include/asm/io.h | 2 -- arch/x86/include/asm/pmem.h | 2 ++ drivers/acpi/Kconfig | 1 + drivers/acpi/nfit.c | 55 ++++++++++++++++++++++----------------- drivers/acpi/nfit.h | 16 ++++++++---- lib/Kconfig | 3 +++ tools/testing/nvdimm/Kbuild | 2 ++ tools/testing/nvdimm/test/iomap.c | 30 +++++++++++++++++++-- tools/testing/nvdimm/test/nfit.c | 10 ++++--- 11 files changed, 88 insertions(+), 36 deletions(-)