From: Eduardo Habkost <ehabkost@redhat.com>
To: "He, Junyan" <junyan.he@intel.com>
Cc: Igor Mammedov <imammedo@redhat.com>,
"junyan.he@gmx.com" <junyan.he@gmx.com>,
"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
"Lai, Paul C" <paul.c.lai@intel.com>,
"xiaoguangrong.eric@gmail.com" <xiaoguangrong.eric@gmail.com>,
"crosthwaite.peter@gmail.com" <crosthwaite.peter@gmail.com>,
"mst@redhat.com" <mst@redhat.com>,
"dgilbert@redhat.com" <dgilbert@redhat.com>,
"quintela@redhat.com" <quintela@redhat.com>,
"stefanha@redhat.com" <stefanha@redhat.com>,
"pbonzini@redhat.com" <pbonzini@redhat.com>,
"rth@twiddle.net" <rth@twiddle.net>,
"Zhang, Yu C" <yu.c.zhang@intel.com>,
"Zhang, Yi Z" <yi.z.zhang@intel.com>
Subject: Re: [Qemu-devel] [PATCH 3/7 V7 RESEND] hostmem-file: add the 'pmem' option
Date: Mon, 9 Jul 2018 15:47:03 -0300 [thread overview]
Message-ID: <20180709184703.GY7451@localhost.localdomain> (raw)
In-Reply-To: <EC8A4E314CF1574AB62C80421BD98339340A8EF5@SHSMSX104.ccr.corp.intel.com>
On Mon, Jul 09, 2018 at 04:43:08AM +0000, He, Junyan wrote:
> Hi:
>
> Do I still need to do something before it can be merged?
Unfortunately this missed 3.0 soft freeze (July 3).
I can still queue it for 3.1, but Igor had a question below that
is still unanswered, and I have a new question below.
If you have to send a new version of a patch, please send it as a
new version (e.g. "v8" instead of "v7 RESEND"). I thought this
patch was the same as "[PATCH 3/7 V7]".
Questions below:
[...]
> > +static void file_memory_backend_set_pmem(Object *o, bool value, Error
> > +**errp) {
> > + HostMemoryBackend *backend = MEMORY_BACKEND(o);
> > + HostMemoryBackendFile *fb = MEMORY_BACKEND_FILE(o);
> > +
> > + if (host_memory_backend_mr_inited(backend)) {
> > + error_setg(errp, "cannot change property 'pmem' of %s '%s'",
> > + object_get_typename(o),
> > + object_get_canonical_path_component(o));
> > + return;
> > + }
> > +
> > +#ifndef CONFIG_LIBPMEM
> > + if (value) {
> > + error_report("Lack of libpmem support while setting the 'pmem=on'"
> > + " of %s '%s'. We can not ensure the persistence of it"
> > + " without libpmem support, this may cause serious"
> > + " problems." , object_get_typename(o),
> > + object_get_canonical_path_component(o));
> > + exit(1);
Why error_report()+exit() instead of error_setg(errp)?
> > + }
> > +#endif
> > +
> > + fb->is_pmem = value;
> > +}
> > +
[...]
> > static void file_backend_instance_finalize(Object *o) diff --git
> > a/docs/nvdimm.txt b/docs/nvdimm.txt index 8b48fb4..2f7d348 100644
> > --- a/docs/nvdimm.txt
> > +++ b/docs/nvdimm.txt
> > @@ -180,3 +180,21 @@ supports CPU Cache Flush and Memory Controller Flush on Power Loss, etc.
> >
> > For a complete list of the flags available and for more detailed
> > descriptions, please consult the ACPI spec.
> > +
> > +guest software that this vNVDIMM device contains a region that cannot
> > +accept persistent writes. In result, for example, the guest Linux
> > +NVDIMM driver, marks such vNVDIMM device as read-only.
> > +
> > +If the vNVDIMM backend is on the host persistent memory that can be
> > +accessed in SNIA NVM Programming Model [1] (e.g., Intel NVDIMM), it's
> > +suggested to set the 'pmem' option of memory-backend-file to 'on'.
> > +When 'pmem=on' and QEMU is built with libpmem [2] support (configured
> > +with --enable-libpmem), QEMU will take necessary operations to
> > +guarantee the persistence of its own writes to the vNVDIMM backend
> > +(e.g., in vNVDIMM label emulation and live migration).
> will libpmem guarantee data persistence even if backend's file is not on persistent memory?
>
>
--
Eduardo
prev parent reply other threads:[~2018-07-09 18:47 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-06-19 3:28 [Qemu-devel] [PATCH 3/7 V7 RESEND] hostmem-file: add the 'pmem' option junyan.he
2018-06-21 13:20 ` Igor Mammedov
2018-07-09 4:43 ` He, Junyan
2018-07-09 18:47 ` Eduardo Habkost [this message]
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=20180709184703.GY7451@localhost.localdomain \
--to=ehabkost@redhat.com \
--cc=crosthwaite.peter@gmail.com \
--cc=dgilbert@redhat.com \
--cc=imammedo@redhat.com \
--cc=junyan.he@gmx.com \
--cc=junyan.he@intel.com \
--cc=mst@redhat.com \
--cc=paul.c.lai@intel.com \
--cc=pbonzini@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=quintela@redhat.com \
--cc=rth@twiddle.net \
--cc=stefanha@redhat.com \
--cc=xiaoguangrong.eric@gmail.com \
--cc=yi.z.zhang@intel.com \
--cc=yu.c.zhang@intel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).