From: Pankaj Gupta <pagupta@redhat.com>
To: Yasunori Goto <y-goto@jp.fujitsu.com>
Cc: Luiz Capitulino <lcapitulino@redhat.com>,
Stefan Hajnoczi <stefanha@gmail.com>,
qemu-devel@nongnu.org, NVDIMM-ML <linux-nvdimm@lists.01.org>,
dan j williams <dan.j.williams@intel.com>
Subject: Re: [Qemu-devel] Questions about vNVDIMM on qemu/KVM
Date: Mon, 4 Jun 2018 04:03:06 -0400 (EDT) [thread overview]
Message-ID: <120916025.39666078.1528099386072.JavaMail.zimbra@redhat.com> (raw)
In-Reply-To: <20180601115429.GL8687@stefanha-x1.localdomain>
Hi,
>
> > I'm investigating status of vNVDIMM on qemu/KVM,
> > and I have some questions about it. I'm glad if anyone answer them.
> >
> > In my understanding, qemu/KVM has a feature to show NFIT for guest,
> > and it will be still updated about platform capability with this patch set.
> > https://lists.gnu.org/archive/html/qemu-devel/2018-05/msg04756.html
> >
> > And libvirt also supports this feature with <memory model='nvdimm'>
> > https://libvirt.org/formatdomain.html#elementsMemory
> >
> >
> > However, virtio-pmem is developing now, and it is better
> > for archtectures to detect regions of NVDIMM without ACPI (like s390x)
> > In addition, It is also necessary to flush guest contents on vNVDIMM
> > who has a backend-file.
> >
> >
> > Q1) Does ACPI.NFIT bus of qemu/kvm remain with virtio-pmem?
No.
> > How do each roles become it if both NFIT and virtio-pmem will be
> > available?
There are two main use cases:
1] DAX memory region pass-through to guest:
-------------------------------------------
As this region is present in actual physical NVDIMM device and exposed to guest,
ACPI/NFIT way is used. If all the persistent memory is used by only this way we
don't need 'virtio-pmem'.
2] Emulated DAX memory region in host passed to guest:
--------------------------------------------------------
If this type of region is exposed to guest, it will be preferable to use
'virtio-pmem'.
This is regular host memory which is mmaped in guest address space for emulating
persistent memory. Guest writes are present in host page cache and not assured to be
written on backing disk without an explicit flush/sync call.
'virtio-pmem' will solve the problem of flushing guest writes present in host page cache.
With filesystems at host which use journal-ling like (ext4, xfs), they automatically call
'fsync' at regular intervals. but still there is not 100% assurance of all write persistence until
an explicit flush is done from guest. So, we need an additional fsync to flush guest writes to
backing disk. We are using this approach to avoid using guest page cache and keep page cache management
of all the guests at host side.
If both ACPI NFIT and virtio-pmem are present, both will have their corresponding memory regions and
defined by memory type "Persistent shared Memory" in case of virtio-pmem and "Persistent Memory" for
ACPI NVDIMM. This is to differentiate both the memory types.
> > If my understanding is correct, both NFIT and virtio-pmem is used to
> > detect vNVDIMM regions, but only one seems to be necessary....
> >
> > Otherwize, is the NFIT bus just for keeping compatibility,
> > and virtio-pmem is promising way?
> >
> >
> > Q2) What bus is(will be?) created for virtio-pmem?
> > I could confirm the bus of NFIT is created with <memory
> > model='nvdimm'>,
For virtio-pmem also its nvdimm bus.
> > and I heard other bus will be created for virtio-pmem, but I could not
> > find what bus is created concretely.
> > ---
> > # ndctl list -B
> > {
> > "provider":"ACPI.NFIT",
> > "dev":"ndbus0"
> > }
> > ---
> >
> > I think it affects what operations user will be able to, and what
> > notification is necessary for vNVDIMM.
> > ACPI defines some operations like namespace controll, and notification
> > for NVDIMM health status or others.
> > (I suppose that other status notification might be necessary for
> > vNVDIMM,
> > but I'm not sure yet...)
For virtio-pmem, we are not providing advance features like namespace and various
other features which ACPI/NVDIMM hardware provides. This is just to keep paravirt
device simple.
Moreover I have not yet looked at ndctl side of things. I am not 100% sure how
ndctl will handle 'virtio-pmem'.
Adding 'Dan' in loop, he can add his thoughts.
Thanks,
Pankaj
> >
> > If my understanding is wrong, please correct me.
> >
> > Thanks,
> > ---
> > Yasunori Goto
> >
> >
> >
>
next prev parent reply other threads:[~2018-06-04 8:03 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-05-23 5:08 [Qemu-devel] Questions about vNVDIMM on qemu/KVM Yasunori Goto
2018-05-23 18:39 ` Dan Williams
2018-05-24 7:19 ` Yasunori Goto
2018-05-24 14:08 ` Dan Williams
2018-05-25 5:02 ` Yasunori Goto
2018-06-01 11:54 ` Stefan Hajnoczi
2018-06-04 8:03 ` Pankaj Gupta [this message]
2018-06-06 1:44 ` Yasunori Goto
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=120916025.39666078.1528099386072.JavaMail.zimbra@redhat.com \
--to=pagupta@redhat.com \
--cc=dan.j.williams@intel.com \
--cc=lcapitulino@redhat.com \
--cc=linux-nvdimm@lists.01.org \
--cc=qemu-devel@nongnu.org \
--cc=stefanha@gmail.com \
--cc=y-goto@jp.fujitsu.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).