Re: [Qemu-devel] [PATCH v3 00/32] implement vNVDIMM

[Xiao Guangrong <guangrong.xiao@linux.intel.com>]

On 10/13/2015 12:36 AM, Dan Williams wrote:
> On Sun, Oct 11, 2015 at 9:33 PM, Xiao Guangrong
> <guangrong.xiao@linux.intel.com> wrote:
>>
>>
>> On 10/11/2015 05:17 AM, Dan Williams wrote:
>>>
>>> On Sat, Oct 10, 2015 at 8:52 PM, Xiao Guangrong
>>> <guangrong.xiao@linux.intel.com> wrote:
>>> [..]
>>>>
>>>> ====== Test ======
>>>> In host
>>>> 1) create memory backed file, e.g # dd if=zero of=/tmp/nvdimm bs=1G
>>>> count=10
>>>> 2) append "-object memory-backend-file,share,id=mem1,
>>>>      mem-path=/tmp/nvdimm -device nvdimm,memdev=mem1,reserve-label-data,
>>>>      id=nv1" in QEMU command line
>>>>
>>>> In guest, download the latest upsteam kernel (4.2 merge window) and
>>>> enable
>>>> ACPI_NFIT, LIBNVDIMM and BLK_DEV_PMEM.
>>>> 1) insmod drivers/nvdimm/libnvdimm.ko
>>>> 2) insmod drivers/acpi/nfit.ko
>>>> 3) insmod drivers/nvdimm/nd_btt.ko
>>>> 4) insmod drivers/nvdimm/nd_pmem.ko
>>>> You can see the whole nvdimm device used as a single namespace and
>>>> /dev/pmem0
>>>> appears. You can do whatever on /dev/pmem0 including DAX access.
>>>>
>>>> Currently Linux NVDIMM driver does not support namespace operation on
>>>> this
>>>> kind of PMEM, apply below changes to support dynamical namespace:
>>>>
>>>> @@ -798,7 +823,8 @@ static int acpi_nfit_register_dimms(struct
>>>> acpi_nfit_desc *a
>>>>                           continue;
>>>>                   }
>>>>
>>>> -               if (nfit_mem->bdw && nfit_mem->memdev_pmem)
>>>> +               //if (nfit_mem->bdw && nfit_mem->memdev_pmem)
>>>> +               if (nfit_mem->memdev_pmem)
>>>>                           flags |= NDD_ALIASING;
>>>
>>>
>>> This is just for testing purposes, right?  I expect guests can
>>
>>
>> It's used to validate NVDIMM _DSM method and static namespace following
>> NVDIMM specs...
>
> Static namespaces can be emitted without a label.  Linux needs this to
> support existing "label-less" bare metal NVDIMMs.

This is Linux specific? As i did not see it has been documented in the
spec...

>
>>> sub-divide persistent memory capacity by partitioning the resulting
>>> block device(s).
>>
>>
>> I understand that it's a Linux design... Hmm, can the same expectation
>> apply to PBLK?
>
> BLK-mode is a bit different as those namespaces have both configurable
> sector-size and an optional BTT.  It is possible to expect multiple
> BLK namespaces per a given region with different settings.

Okay, thanks for your nice explanation, Dan!