> > > As above, if linux driver detects the signature "NVDIMM_PFN_INFO" and
> > > a matched checksum, it will know it's safe to write to the reserved
> > > area. Otherwise, it will treat the pmem namespace as a raw device and
> > > store page struct's in the normal RAM.
> >
> > OK, so my worry is
On 08/04/16 10:51, Konrad Rzeszutek Wilk wrote:
> > > > Such a pmem namespace can be created via a userspace tool ndctl and
> > > > then recognized by Linux NVDIMM driver. However, they currently only
> > > > reserve space for Linux kernel's page structs. Therefore, our design
> > > > need to e
On Thu, Aug 04, 2016 at 05:35:12PM +0800, Haozhong Zhang wrote:
> On 08/04/16 03:25, Jan Beulich wrote:
> > >>> On 04.08.16 at 10:52, wrote:
> > > On 08/03/16 17:25, Konrad Rzeszutek Wilk wrote:
> > >> Anyhow, wouldn't this 'sizeof(struct page_info)' depend on the ndctl
> > >> tool and what versio
> > > Such a pmem namespace can be created via a userspace tool ndctl and
> > > then recognized by Linux NVDIMM driver. However, they currently only
> > > reserve space for Linux kernel's page structs. Therefore, our design
> > > need to extend both Linux NVDIMM driver and ndctl to reserve
> >
On 08/04/16 03:25, Jan Beulich wrote:
> >>> On 04.08.16 at 10:52, wrote:
> > On 08/03/16 17:25, Konrad Rzeszutek Wilk wrote:
> >> Anyhow, wouldn't this 'sizeof(struct page_info)' depend on the ndctl
> >> tool and what version was used to create this? What if one version
> >> used 32-bytes for a PA
>>> On 04.08.16 at 10:52, wrote:
> On 08/03/16 17:25, Konrad Rzeszutek Wilk wrote:
>> Anyhow, wouldn't this 'sizeof(struct page_info)' depend on the ndctl
>> tool and what version was used to create this? What if one version
>> used 32-bytes for a PAGE, while another used 64-bytes for a PAGE too?
Hi Konrad,
On 08/03/16 17:25, Konrad Rzeszutek Wilk wrote:
> On Mon, Jul 18, 2016 at 08:29:12AM +0800, Haozhong Zhang wrote:
> > Hi,
> >
>
> Hey!
>
> Thanks for posting! Sorry for the late review. Below are some of my
> comment.
>
Thank you for the review!
[..]
> And is there any need for the
On 08/03/16 19:16, Konrad Rzeszutek Wilk wrote:
> > > 1.4 clwb/clflushopt
> > >
> > > Writes to NVDIMM may be cached by caches, so certain flushing
> > > operations should be performed to make them persistent on
> > > NVDIMM. clwb is used in favor of clflushopt and clflush to flush
> > > write
> > 1.4 clwb/clflushopt
> >
> > Writes to NVDIMM may be cached by caches, so certain flushing
> > operations should be performed to make them persistent on
> > NVDIMM. clwb is used in favor of clflushopt and clflush to flush
> > writes from caches to memory.
> >
> > Details of clwb/clflushop
On Mon, Jul 18, 2016 at 08:29:12AM +0800, Haozhong Zhang wrote:
> Hi,
>
Hey!
Thanks for posting! Sorry for the late review. Below are some of my
comment.
> Following is version 2 of the design doc for supporting vNVDIMM in
> Xen. It's basically the summary of discussion on previous v1 design
>
>>> On 03.08.16 at 12:08, wrote:
> On 08/03/16 03:47, Jan Beulich wrote:
>> >>> On 03.08.16 at 11:37, wrote:
>> > By using the file name, e.g. if I specify vnvdimm = [ 'file=/mnt/dax/foo' ]
>> > in a domain config file, SPA occupied by /mnt/dax/foo are mapped to
>> > the domain. If the same file
On 08/03/16 03:47, Jan Beulich wrote:
> >>> On 03.08.16 at 11:37, wrote:
> > On 08/03/16 02:45, Jan Beulich wrote:
> >> >>> On 03.08.16 at 08:54, wrote:
> >> > On 08/02/16 08:46, Jan Beulich wrote:
> >> >> >>> On 18.07.16 at 02:29, wrote:
> >> >> > (4) Because the reserved area is now used by X
>>> On 03.08.16 at 11:37, wrote:
> On 08/03/16 02:45, Jan Beulich wrote:
>> >>> On 03.08.16 at 08:54, wrote:
>> > On 08/02/16 08:46, Jan Beulich wrote:
>> >> >>> On 18.07.16 at 02:29, wrote:
>> >> > (4) Because the reserved area is now used by Xen hypervisor, it
>> >> > should not be acces
On 08/03/16 02:45, Jan Beulich wrote:
> >>> On 03.08.16 at 08:54, wrote:
> > On 08/02/16 08:46, Jan Beulich wrote:
> >> >>> On 18.07.16 at 02:29, wrote:
> >> > (4) Because the reserved area is now used by Xen hypervisor, it
> >> > should not be accessible by Dom0 any more. Therefore, if a h
>>> On 03.08.16 at 08:54, wrote:
> On 08/02/16 08:46, Jan Beulich wrote:
>> >>> On 18.07.16 at 02:29, wrote:
>> > (4) Because the reserved area is now used by Xen hypervisor, it
>> > should not be accessible by Dom0 any more. Therefore, if a host
>> > pmem device is recorded by Xen hyp
On 08/02/16 08:46, Jan Beulich wrote:
> >>> On 18.07.16 at 02:29, wrote:
> > 4.2.2 Detection of Host pmem Devices
> >
> > The detection and initialize host pmem devices require a non-trivial
> > driver to interact with the corresponding ACPI namespace devices,
> > parse namespace labels and ma
>>> On 18.07.16 at 02:29, wrote:
> 4.2.2 Detection of Host pmem Devices
>
> The detection and initialize host pmem devices require a non-trivial
> driver to interact with the corresponding ACPI namespace devices,
> parse namespace labels and make necessary recovery actions. Instead
> of dupli
On 07/19/16 09:57, Bob Liu wrote:
> Hey Haozhong,
>
> On 07/18/2016 08:29 AM, Haozhong Zhang wrote:
> > Hi,
> >
> > Following is version 2 of the design doc for supporting vNVDIMM in
>
> This version is really good, very clear and included almost everything I'd
> like to know.
>
> > Xen. It's
On 07/19/16 08:58, Tian, Kevin wrote:
> > From: Zhang, Haozhong
> > Sent: Monday, July 18, 2016 5:02 PM
> >
> > On 07/18/16 16:36, Tian, Kevin wrote:
> > > > From: Zhang, Haozhong
> > > > Sent: Monday, July 18, 2016 8:29 AM
> > > >
> > > > Hi,
> > > >
> > > > Following is version 2 of the design d
Hey Haozhong,
On 07/18/2016 08:29 AM, Haozhong Zhang wrote:
> Hi,
>
> Following is version 2 of the design doc for supporting vNVDIMM in
This version is really good, very clear and included almost everything I'd like
to know.
> Xen. It's basically the summary of discussion on previous v1 desig
> From: Zhang, Haozhong
> Sent: Monday, July 18, 2016 5:02 PM
>
> On 07/18/16 16:36, Tian, Kevin wrote:
> > > From: Zhang, Haozhong
> > > Sent: Monday, July 18, 2016 8:29 AM
> > >
> > > Hi,
> > >
> > > Following is version 2 of the design doc for supporting vNVDIMM in
> > > Xen. It's basically the
On 07/18/16 16:36, Tian, Kevin wrote:
> > From: Zhang, Haozhong
> > Sent: Monday, July 18, 2016 8:29 AM
> >
> > Hi,
> >
> > Following is version 2 of the design doc for supporting vNVDIMM in
> > Xen. It's basically the summary of discussion on previous v1 design
> > (https://lists.xenproject.org/
> From: Zhang, Haozhong
> Sent: Monday, July 18, 2016 8:29 AM
>
> Hi,
>
> Following is version 2 of the design doc for supporting vNVDIMM in
> Xen. It's basically the summary of discussion on previous v1 design
> (https://lists.xenproject.org/archives/html/xen-devel/2016-02/msg6.html).
> Any
Hi,
Following is version 2 of the design doc for supporting vNVDIMM in
Xen. It's basically the summary of discussion on previous v1 design
(https://lists.xenproject.org/archives/html/xen-devel/2016-02/msg6.html).
Any comments are welcome. The corresponding patches are WIP.
Thanks,
Haozhong
24 matches
Mail list logo
