qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
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
> > 
> > 
> > 
> 

  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).