From: Pankaj Gupta <pagupta@redhat.com>
To: David Hildenbrand <david@redhat.com>
Cc: Stefan Hajnoczi <stefanha@redhat.com>,
virtio-dev@lists.oasis-open.org, mst@redhat.com,
riel@surriel.com, dan j williams <dan.j.williams@intel.com>,
aarcange@redhat.com, cohuck@redhat.com, lcapitulino@redhat.com,
nilal@redhat.com
Subject: Re: [virtio-dev] Re: [RFC] virtio-pmem: PMEM device spec
Date: Thu, 11 Apr 2019 05:35:56 -0400 (EDT) [thread overview]
Message-ID: <464466266.20997635.1554975356303.JavaMail.zimbra@redhat.com> (raw)
In-Reply-To: <f72cb6cc-397a-4472-165b-1b897e4f67df@redhat.com>
> >>>> --- /dev/null
> >>>> +++ b/virtio-pmem.tex
> >>>> @@ -0,0 +1,134 @@
> >>>> +\section{PMEM Device}\label{sec:Device Types / PMEM Device}
> >>>> +
> >>>> +The virtio pmem is a fake persistent memory (NVDIMM) device
> >>>> +used to bypass the guest page cache and provide a virtio
> >>>> +based asynchronous flush mechanism. This avoids the need
> >>>
> >>> Is there anything "fake" about virtio-pmem from the perspective of the
> >>> device interface?
> >>>
> >>> What you are describing is one use case. But on a platform that doesn't
> >>> have existing physical NVDIMM interfaces, ACPI, etc maybe virtio-pmem
> >>> would be used to pass through physical NVDIMMs from the host? If you
> >>> agree, then it might make sense to describe the device simply as a
> >>> persistent memory device and give "fake NVDIMM" as an example use case
> >>> in a separate paragraph. This would make the text more future-proof.
> >>
> >> Very good point. E.g. on x86-64, we might want to pass a real NVDIMM to
> >> the guest using virtio-pmem, if our guest VM e.g. has no ACPI configured.
> >>
> >> In this case, it would be helpful to indicate if the flushing interface
> >> is to be used, or if other flushing (e.g. like NVDIMMs) is to be used.
> >>
> >
> > Yes. Agree. This is a very good point, will consider pass-through of
> > real NVDIMM device for architectures don't support ACPI.
> >
> > Yes, corresponding flushing mechanism should be mentioned but I am not sure
> > if it should be mentioned in device specification?
>
> Well there has to be a way to indicate how to flush writes, no?
yes.
Thanks,
Pankaj
---------------------------------------------------------------------
To unsubscribe, e-mail: virtio-dev-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: virtio-dev-help@lists.oasis-open.org
next prev parent reply other threads:[~2019-04-11 9:35 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-03-26 14:35 [virtio-dev] [RFC] virtio-pmem: PMEM device spec Pankaj Gupta
2019-04-10 10:02 ` [virtio-dev] " Cornelia Huck
2019-04-10 10:33 ` Pankaj Gupta
2019-04-10 14:42 ` Stefan Hajnoczi
2019-04-10 14:56 ` David Hildenbrand
2019-04-11 9:12 ` Pankaj Gupta
2019-04-11 9:14 ` David Hildenbrand
2019-04-11 9:35 ` Pankaj Gupta [this message]
2019-04-11 9:02 ` Pankaj Gupta
2019-06-21 20:33 ` [virtio-dev] " Michael S. Tsirkin
2019-06-24 8:58 ` Pankaj Gupta
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=464466266.20997635.1554975356303.JavaMail.zimbra@redhat.com \
--to=pagupta@redhat.com \
--cc=aarcange@redhat.com \
--cc=cohuck@redhat.com \
--cc=dan.j.williams@intel.com \
--cc=david@redhat.com \
--cc=lcapitulino@redhat.com \
--cc=mst@redhat.com \
--cc=nilal@redhat.com \
--cc=riel@surriel.com \
--cc=stefanha@redhat.com \
--cc=virtio-dev@lists.oasis-open.org \
/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.