qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH 00/15] NVDIMM: introduce nvdimm label support


From: Dan Williams
Subject: Re: [Qemu-devel] [PATCH 00/15] NVDIMM: introduce nvdimm label support
Date: Tue, 22 Mar 2016 08:37:40 -0700

On Thu, Mar 17, 2016 at 3:04 AM, Stefan Hajnoczi <address@hidden> wrote:
> On Thu, Mar 17, 2016 at 04:32:46PM +0800, Xiao Guangrong wrote:
>> This patchset is against commit d4207b223eef3 (fw-cfg: support writeable
>> blobs) on pci branch of Michael's git tree and can be found at:
>>       https://github.com/xiaogr/qemu.git nvdimm-label-v1
>>
>> This is the last part of vNVDIMM implementation which introduces nvdimm
>> label support
>>
>> 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;
>
> Not a blocker for this patch series, but why does Linux require Block
> Device Window to enable namespace support?

A namespace label delineates aliased capacity between the pmem and
block-window access mechanisms.  If there is no aliased capacity then
the size of the namespace can be directly derived from the nfit range
and a label need not be considered.  Contiguous (dax-capable)
sub-divisions of pmem can be had via partitioning of the resulting
gendisk.

> Will this be changed upstream in the Linux driver?

There are no plans to change this.  Also note that the above change
only allows one allocation which is probably not what we want.

All this said, the hypervisor could simulate aliased block-window
capacity in a similar manner as nfit_test.  This would allow
dis-contiguous allocations of the persistent memory range passed to a
guest via this label mechanism.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]