From: "Dr. David Alan Gilbert" <dgilbert@redhat.com>
To: qemu-devel@nongnu.org, Eduardo Habkost <ehabkost@redhat.com>,
Igor Mammedov <imammedo@redhat.com>,
Paolo Bonzini <pbonzini@redhat.com>,
mst@redhat.com, Xiao Guangrong <xiaoguangrong.eric@gmail.com>,
Juan Quintela <quintela@redhat.com>,
Stefan Hajnoczi <stefanha@redhat.com>,
Dan Williams <dan.j.williams@intel.com>
Subject: Re: [Qemu-devel] [PATCH v2 5/8] migration/ram: ensure write persistence on loading zero pages to PMEM
Date: Wed, 7 Feb 2018 12:59:00 +0000 [thread overview]
Message-ID: <20180207125859.GG2665@work-vm> (raw)
In-Reply-To: <20180207125141.cajtcvlsatwplfxh@hz-desktop>
* Haozhong Zhang (haozhong.zhang@intel.com) wrote:
> On 02/07/18 19:52 +0800, Haozhong Zhang wrote:
> > On 02/07/18 11:38 +0000, Dr. David Alan Gilbert wrote:
> > > * Haozhong Zhang (haozhong.zhang@intel.com) wrote:
> > > > When loading a zero page, check whether it will be loaded to
> > > > persistent memory If yes, load it by libpmem function
> > > > pmem_memset_nodrain(). Combined with a call to pmem_drain() at the
> > > > end of RAM loading, we can guarantee all those zero pages are
> > > > persistently loaded.
> > >
> > > I'm surprised pmem is this invasive to be honest; I hadn't expected
> > > the need for special memcpy's etc everywhere. We're bound to miss some.
> > > I assume there's separate kernel work needed to make postcopy work;
> > > certainly the patches here don't seem to touch the postcopy path.
> >
> > This link at
> > https://wiki.qemu.org/Features/PostCopyLiveMigration#Conflicts shows
> > that postcopy with memory-backend-file requires kernel support. Can
> > you point me the details of the required kernel support, so that I can
> > understand what would be needed to NVDIMM postcopy?
>
> I saw test_ramblock_postcopiable() requires the ram block not be
> mmap'ed with MAP_SHARED. The only pmem device (i.e., device DAX e.g.,
> /dev/dax0.0) that can be safely used as the backend of vNVDIMM must be
> shared mapped which is required by kernel, so postcopy does not work
> with pmem right now. Even if the private mmap was supported for device
> dax, it would still make little sense to private mmap it in QEMU,
> because vNVDIMM intends to be non-volatile.
I've got patches which do shareable for vhost-user at the moment;
(I've posted a few versions and I'm working on an updated set).
However, it's probably more than just the shareable that needs thinking
about for a device like that.
Dave
> Haozhong
--
Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK
next prev parent reply other threads:[~2018-02-07 12:59 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-02-07 7:33 [Qemu-devel] [PATCH v2 0/8] nvdimm: guarantee persistence of QEMU writes to persistent memory Haozhong Zhang
2018-02-07 7:33 ` [Qemu-devel] [PATCH v2 1/8] memory, exec: switch file ram allocation functions to 'flags' parameters Haozhong Zhang
2018-02-07 7:33 ` [Qemu-devel] [PATCH v2 2/8] hostmem-file: add the 'pmem' option Haozhong Zhang
2018-02-07 7:33 ` [Qemu-devel] [PATCH v2 3/8] configure: add libpmem support Haozhong Zhang
2018-02-07 7:33 ` [Qemu-devel] [PATCH v2 4/8] mem/nvdimm: ensure write persistence to PMEM in label emulation Haozhong Zhang
2018-02-09 14:27 ` Stefan Hajnoczi
2018-02-09 14:57 ` Haozhong Zhang
2018-02-12 13:55 ` Stefan Hajnoczi
2018-02-07 7:33 ` [Qemu-devel] [PATCH v2 5/8] migration/ram: ensure write persistence on loading zero pages to PMEM Haozhong Zhang
2018-02-07 10:17 ` Pankaj Gupta
2018-02-07 11:18 ` Haozhong Zhang
2018-02-07 11:30 ` Pankaj Gupta
2018-02-07 11:38 ` Dr. David Alan Gilbert
2018-02-07 11:52 ` Haozhong Zhang
2018-02-07 12:51 ` Haozhong Zhang
2018-02-07 12:59 ` Dr. David Alan Gilbert [this message]
2018-02-07 14:10 ` Pankaj Gupta
2018-02-07 12:56 ` Dr. David Alan Gilbert
2018-02-07 7:33 ` [Qemu-devel] [PATCH v2 6/8] migration/ram: ensure write persistence on loading normal " Haozhong Zhang
2018-02-07 11:49 ` Dr. David Alan Gilbert
2018-02-07 12:02 ` Haozhong Zhang
2018-02-07 7:33 ` [Qemu-devel] [PATCH v2 7/8] migration/ram: ensure write persistence on loading compressed " Haozhong Zhang
2018-02-07 11:54 ` Dr. David Alan Gilbert
2018-02-07 12:15 ` Haozhong Zhang
2018-02-07 13:03 ` Dr. David Alan Gilbert
2018-02-07 13:20 ` Haozhong Zhang
2018-02-07 13:24 ` Dr. David Alan Gilbert
2018-02-07 18:05 ` Dan Williams
2018-02-07 18:08 ` Dr. David Alan Gilbert
2018-02-07 18:31 ` Dan Williams
2018-02-07 18:37 ` Dr. David Alan Gilbert
2018-02-07 22:43 ` Dan Williams
2018-02-07 7:33 ` [Qemu-devel] [PATCH v2 8/8] migration/ram: ensure write persistence on loading xbzrle " Haozhong Zhang
2018-02-07 13:08 ` Dr. David Alan Gilbert
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20180207125859.GG2665@work-vm \
--to=dgilbert@redhat.com \
--cc=dan.j.williams@intel.com \
--cc=ehabkost@redhat.com \
--cc=imammedo@redhat.com \
--cc=mst@redhat.com \
--cc=pbonzini@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=quintela@redhat.com \
--cc=stefanha@redhat.com \
--cc=xiaoguangrong.eric@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.