From: Andrzej Jakowski <andrzej.jakowski@linux.intel.com>
To: Stefan Hajnoczi <stefanha@gmail.com>
Cc: Kevin Wolf <kwolf@redhat.com>,
Haozhong Zhang <haozhong.zhang@intel.com>,
qemu block <qemu-block@nongnu.org>,
Dave Gilbert <dgilbert@redhat.com>,
qemu-devel <qemu-devel@nongnu.org>,
Zhang Yi <yi.z.zhang@linux.intel.com>,
"He, Junyan" <junyan.he@intel.com>,
kbusch@kernel.org, Max Reitz <mreitz@redhat.com>
Subject: Re: [PATCH RESEND v2] block/nvme: introduce PMR support from NVMe 1.4 spec
Date: Wed, 11 Mar 2020 15:54:31 -0700 [thread overview]
Message-ID: <12576914-0ef4-efd2-355a-cff3f4eeae69@linux.intel.com> (raw)
In-Reply-To: <CAJSP0QXatOWgicLo5sGt9KA2QupC2qXD2LCdHWKgHFdzgt9pEg@mail.gmail.com>
On 3/11/20 2:20 AM, Stefan Hajnoczi wrote:
> Please try:
>
> $ git grep pmem
>
> backends/hostmem-file.c is the backend that can be used and the
> pmem_persist() API can be used to flush writes.
I've reworked this patch into hostmem-file type of backend.
From simple tests in virtual machine: writing to PMR region
and then reading from it after VM power cycle I have observed that
there is no persistency.
I guess that persistent behavior can be achieved if memory backend file
resides on actual persistent memory in VMM. I haven't found mechanism to
persist memory backend file when it resides in the file system on block
storage. My original mmap + msync based solution worked well there.
I believe that main problem with mmap was with "ifdef _WIN32" that made it
platform specific and w/o it patchew CI complained.
Is there a way that I could rework mmap + msync solution so it would fit
into qemu design?
next prev parent reply other threads:[~2020-03-11 22:59 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-03-06 22:38 [PATCH RESEND v2] block/nvme: introduce PMR support from NVMe 1.4 spec Andrzej Jakowski
2020-03-10 9:51 ` Stefan Hajnoczi
2020-03-10 20:09 ` Andrzej Jakowski
2020-03-11 9:20 ` Stefan Hajnoczi
2020-03-11 22:54 ` Andrzej Jakowski [this message]
2020-03-12 6:08 ` Klaus Birkelund Jensen
2020-03-16 11:32 ` Stefan Hajnoczi
2020-03-16 17:10 ` Andrzej Jakowski
2020-03-17 11:23 ` Stefan Hajnoczi
2020-03-18 4:20 ` Andrzej Jakowski
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=12576914-0ef4-efd2-355a-cff3f4eeae69@linux.intel.com \
--to=andrzej.jakowski@linux.intel.com \
--cc=dgilbert@redhat.com \
--cc=haozhong.zhang@intel.com \
--cc=junyan.he@intel.com \
--cc=kbusch@kernel.org \
--cc=kwolf@redhat.com \
--cc=mreitz@redhat.com \
--cc=qemu-block@nongnu.org \
--cc=qemu-devel@nongnu.org \
--cc=stefanha@gmail.com \
--cc=yi.z.zhang@linux.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 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.