Re: [Linux-nvdimm] [PATCH 05/21] nfit-test: manufactured NFITs for interface development

2015-04-28 Thread Dan Williams
On Tue, Apr 28, 2015 at 5:54 AM, Christoph Hellwig  wrote:
> Eww, the --wrap stuff is too ugly too live.

Since when are unit tests pretty?

> Just implement the
> implemenetation of persistent nvdimms into qemu where it belongs.

Ugh, no, I'm not keen to introduce yet another roadblock to running
the tests and another degree of freedom for things to bit rot.  It
will never be pretty, but the implementation at least gets slightly
cleaner in v2 with the removal of the wrapping for nd_blk_do_io().
It's also worth noting that 0day is currently running our unit tests.

> Note that having a not actually persistent implementation that register
> with the subsystems which doesn't need these hacks still sounds ok to
> me, altough I suspect most users would much prefer the virtualization
> based variant.

KVM NFIT enabling is happening, but I don't think it is useful as a
unit test vehicle.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [Linux-nvdimm] [PATCH 05/21] nfit-test: manufactured NFITs for interface development

2015-04-28 Thread Christoph Hellwig
Eww, the --wrap stuff is too ugly too live.  Just implement the
implemenetation of persistent nvdimms into qemu where it belongs.

Note that having a not actually persistent implementation that register
with the subsystems which doesn't need these hacks still sounds ok to
me, altough I suspect most users would much prefer the virtualization
based variant.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [Linux-nvdimm] [PATCH 05/21] nfit-test: manufactured NFITs for interface development

2015-04-24 Thread Dan Williams
On Fri, Apr 24, 2015 at 2:59 PM, Linda Knippers  wrote:
> On 4/24/2015 5:50 PM, Dan Williams wrote:
>> On Fri, Apr 24, 2015 at 2:47 PM, Linda Knippers  
>> wrote:
>>> On 4/17/2015 9:35 PM, Dan Williams wrote:
>>> :
 diff --git a/drivers/block/nd/Kconfig b/drivers/block/nd/Kconfig
 index 5fa74f124b3e..0106b3807202 100644
 --- a/drivers/block/nd/Kconfig
 +++ b/drivers/block/nd/Kconfig
 @@ -41,4 +41,24 @@ config NFIT_ACPI
 register the platform-global NFIT blob with the core.  Also
 enables the core to craft ACPI._DSM messages for platform/dimm
 configuration.
 +
 +config NFIT_TEST
 + tristate "NFIT TEST: Manufactured NFIT for interface testing"
 + depends on DMA_CMA
 + depends on ND_CORE=m
 + depends on m
 + help
 +   For development purposes register a manufactured
 +   NFIT table to verify the resulting device model topology.
 +   Note, this module arranges for ioremap_cache() to be
 +   overridden locally to allow simulation of system-memory as an
 +   io-memory-resource.
 +
 +   Note, this test expects to be able to find at least
 +   256MB of CMA space (CONFIG_CMA_SIZE_MBYTES) or it will fail to
>>>
>>> It seems to actually be wanting >= 584MB.
>>
>> Ah, true, this Kconfig text is stale.  Will fix.
>
> Thanks.  One more question...
>
>> +#ifdef CONFIG_CMA_SIZE_MBYTES
>> +#define CMA_SIZE_MBYTES CONFIG_CMA_SIZE_MBYTES
>> +#else
>> +#define CMA_SIZE_MBYTES 0
>> +#endif
>> +
>> +static __init int nfit_test_init(void)
>> +{
>> + int rc, i;
>> +
>> + if (CMA_SIZE_MBYTES < 584) {
>> + pr_err("need CONFIG_CMA_SIZE_MBYTES >= 584 to load\n");
>> + return -EINVAL;
>> + }
>> +
>
> Since the kernel takes a cma= boot parameter, it would be nice if
> this check is against what the kernel is using rather than the config
> option.  Is that possible?

Yeah, that would be more friendly.  I also think we can reduce the BLK
aperture sizes.  Since those don't need to be DAX capable they can
come from vmalloc memory rather than CMA.  I'll take a look.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [Linux-nvdimm] [PATCH 05/21] nfit-test: manufactured NFITs for interface development

2015-04-24 Thread Linda Knippers
On 4/24/2015 5:50 PM, Dan Williams wrote:
> On Fri, Apr 24, 2015 at 2:47 PM, Linda Knippers  wrote:
>> On 4/17/2015 9:35 PM, Dan Williams wrote:
>> :
>>> diff --git a/drivers/block/nd/Kconfig b/drivers/block/nd/Kconfig
>>> index 5fa74f124b3e..0106b3807202 100644
>>> --- a/drivers/block/nd/Kconfig
>>> +++ b/drivers/block/nd/Kconfig
>>> @@ -41,4 +41,24 @@ config NFIT_ACPI
>>> register the platform-global NFIT blob with the core.  Also
>>> enables the core to craft ACPI._DSM messages for platform/dimm
>>> configuration.
>>> +
>>> +config NFIT_TEST
>>> + tristate "NFIT TEST: Manufactured NFIT for interface testing"
>>> + depends on DMA_CMA
>>> + depends on ND_CORE=m
>>> + depends on m
>>> + help
>>> +   For development purposes register a manufactured
>>> +   NFIT table to verify the resulting device model topology.
>>> +   Note, this module arranges for ioremap_cache() to be
>>> +   overridden locally to allow simulation of system-memory as an
>>> +   io-memory-resource.
>>> +
>>> +   Note, this test expects to be able to find at least
>>> +   256MB of CMA space (CONFIG_CMA_SIZE_MBYTES) or it will fail to
>>
>> It seems to actually be wanting >= 584MB.
> 
> Ah, true, this Kconfig text is stale.  Will fix.

Thanks.  One more question...

> +#ifdef CONFIG_CMA_SIZE_MBYTES
> +#define CMA_SIZE_MBYTES CONFIG_CMA_SIZE_MBYTES
> +#else
> +#define CMA_SIZE_MBYTES 0
> +#endif
> +
> +static __init int nfit_test_init(void)
> +{
> + int rc, i;
> +
> + if (CMA_SIZE_MBYTES < 584) {
> + pr_err("need CONFIG_CMA_SIZE_MBYTES >= 584 to load\n");
> + return -EINVAL;
> + }
> +

Since the kernel takes a cma= boot parameter, it would be nice if
this check is against what the kernel is using rather than the config
option.  Is that possible?

-- ljk
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [Linux-nvdimm] [PATCH 05/21] nfit-test: manufactured NFITs for interface development

2015-04-24 Thread Dan Williams
On Fri, Apr 24, 2015 at 2:47 PM, Linda Knippers  wrote:
> On 4/17/2015 9:35 PM, Dan Williams wrote:
> :
>> diff --git a/drivers/block/nd/Kconfig b/drivers/block/nd/Kconfig
>> index 5fa74f124b3e..0106b3807202 100644
>> --- a/drivers/block/nd/Kconfig
>> +++ b/drivers/block/nd/Kconfig
>> @@ -41,4 +41,24 @@ config NFIT_ACPI
>> register the platform-global NFIT blob with the core.  Also
>> enables the core to craft ACPI._DSM messages for platform/dimm
>> configuration.
>> +
>> +config NFIT_TEST
>> + tristate "NFIT TEST: Manufactured NFIT for interface testing"
>> + depends on DMA_CMA
>> + depends on ND_CORE=m
>> + depends on m
>> + help
>> +   For development purposes register a manufactured
>> +   NFIT table to verify the resulting device model topology.
>> +   Note, this module arranges for ioremap_cache() to be
>> +   overridden locally to allow simulation of system-memory as an
>> +   io-memory-resource.
>> +
>> +   Note, this test expects to be able to find at least
>> +   256MB of CMA space (CONFIG_CMA_SIZE_MBYTES) or it will fail to
>
> It seems to actually be wanting >= 584MB.

Ah, true, this Kconfig text is stale.  Will fix.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [Linux-nvdimm] [PATCH 05/21] nfit-test: manufactured NFITs for interface development

2015-04-24 Thread Linda Knippers
On 4/17/2015 9:35 PM, Dan Williams wrote:
:
> diff --git a/drivers/block/nd/Kconfig b/drivers/block/nd/Kconfig
> index 5fa74f124b3e..0106b3807202 100644
> --- a/drivers/block/nd/Kconfig
> +++ b/drivers/block/nd/Kconfig
> @@ -41,4 +41,24 @@ config NFIT_ACPI
> register the platform-global NFIT blob with the core.  Also
> enables the core to craft ACPI._DSM messages for platform/dimm
> configuration.
> +
> +config NFIT_TEST
> + tristate "NFIT TEST: Manufactured NFIT for interface testing"
> + depends on DMA_CMA
> + depends on ND_CORE=m
> + depends on m
> + help
> +   For development purposes register a manufactured
> +   NFIT table to verify the resulting device model topology.
> +   Note, this module arranges for ioremap_cache() to be
> +   overridden locally to allow simulation of system-memory as an
> +   io-memory-resource.
> +
> +   Note, this test expects to be able to find at least
> +   256MB of CMA space (CONFIG_CMA_SIZE_MBYTES) or it will fail to

It seems to actually be wanting >= 584MB.

-- ljk

> +   load.  Kconfig does not allow for numerical value
> +   dependencies, so we can only warn at runtime.
> +
> +   Say N unless you are doing development of the 'nd' subsystem.
> +
>  endif
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


[PATCH 05/21] nfit-test: manufactured NFITs for interface development

2015-04-17 Thread Dan Williams
Manually create and register NFITs to describe 2 topologies.  Topology1
is an advanced plausible configuration for BLK/PMEM aliased NVDIMMs.
Topology2 is an example configuration for current platforms that only
ship with a persistent address range.

 Kernel provider "nfit_test.0" produces an NFIT with the following attributes:

  (a)   (b)   DIMM   BLK-REGION
   +---++++
 +--+  |   pm0.0   | blk2.0 | pm1.0  | blk2.1 |0  region2
 | imc0 +--+- - - region0- - - ++++
 +--+---+  |   pm0.0   | blk3.0 | pm1.0  | blk3.1 |1  region3
|  +---+vv+
 +--+---+   | |
 | cpu0 | region1
 +--+---+   | |
|  +^^+
 +--+---+  |   blk4.0   | pm1.0  | blk4.0 |2  region4
 | imc1 +--+|++
 +--+  |   blk5.0   | pm1.0  | blk5.0 |3  region5
   ++++

 *) In this layout we have four dimms and two memory controllers in one
socket.  Each unique interface ("block" or "pmem") to DPA space
is identified by a region device with a dynamically assigned id.

 *) The first portion of dimm0 and dimm1 are interleaved as REGION0.
A single "pmem" namespace is created in the REGION0-"spa"-range
that spans dimm0 and dimm1 with a user-specified name of "pm0.0".
Some of that interleaved "spa" range is reclaimed as "bdw"
accessed space starting at offset (a) into each dimm.  In that
reclaimed space we create two "bdw" "namespaces" from REGION2 and
REGION3 where "blk2.0" and "blk3.0" are just human readable names
that could be set to any user-desired name in the label.

 *) In the last portion of dimm0 and dimm1 we have an interleaved
"spa" range, REGION1, that spans those two dimms as well as dimm2
and dimm3.  Some of REGION1 allocated to a "pmem" namespace named
"pm1.0" the rest is reclaimed in 4 "bdw" namespaces (for each
dimm in the interleave set), "blk2.1", "blk3.1", "blk4.0", and
"blk5.0".

 *) The portion of dimm2 and dimm3 that do not participate in the
REGION1 interleaved "spa" range (i.e. the DPA address below
offset (b) are also included in the "blk4.0" and "blk5.0"
namespaces.  Note, that this example shows that "bdw" namespaces
don't need to be contiguous in DPA-space.

 Kernel provider "nfit_test.1" produces an NFIT with the following attributes:

 region2
 +-+
 |-|
 ||   pm2.0   ||
 |-|
 +-+

 *) Describes a simple system-physical-address range with no backing
dimm or interleave description.

Signed-off-by: Dan Williams 
---
 drivers/block/nd/Kconfig  |   20 +
 drivers/block/nd/Makefile |   16 +
 drivers/block/nd/nfit.h   |9 
 drivers/block/nd/test/Makefile|5 
 drivers/block/nd/test/iomap.c |  148 ++
 drivers/block/nd/test/nfit.c  |  930 +
 drivers/block/nd/test/nfit_test.h |   25 +
 7 files changed, 1153 insertions(+)
 create mode 100644 drivers/block/nd/test/Makefile
 create mode 100644 drivers/block/nd/test/iomap.c
 create mode 100644 drivers/block/nd/test/nfit.c
 create mode 100644 drivers/block/nd/test/nfit_test.h

diff --git a/drivers/block/nd/Kconfig b/drivers/block/nd/Kconfig
index 5fa74f124b3e..0106b3807202 100644
--- a/drivers/block/nd/Kconfig
+++ b/drivers/block/nd/Kconfig
@@ -41,4 +41,24 @@ config NFIT_ACPI
  register the platform-global NFIT blob with the core.  Also
  enables the core to craft ACPI._DSM messages for platform/dimm
  configuration.
+
+config NFIT_TEST
+   tristate "NFIT TEST: Manufactured NFIT for interface testing"
+   depends on DMA_CMA
+   depends on ND_CORE=m
+   depends on m
+   help
+ For development purposes register a manufactured
+ NFIT table to verify the resulting device model topology.
+ Note, this module arranges for ioremap_cache() to be
+ overridden locally to allow simulation of system-memory as an
+ io-memory-resource.
+
+ Note, this test expects to be able to find at least
+ 256MB of CMA space (CONFIG_CMA_SIZE_MBYTES) or it will fail to
+ load.  Kconfig does not allow for numerical value
+ dependencies, so we can only warn at runtime.
+
+ Say N unless you are doing development of the 'nd' subsystem.
+
 endif
diff --git a/drivers/block/nd/Makefile b/drivers/block/nd/Makefile
index 22701ab7dcae..c6bec0c185c5 100644
--- a/drivers/block/nd/Makefile
+++ b/drivers/block/nd/Makefile
@@ -1,3 +1,19 @@
+obj-$(CONFIG_NFIT_TE