From: "Kani, Toshimitsu" <toshi.kani@hpe.com>
To: "dan.j.williams@intel.com" <dan.j.williams@intel.com>,
"ross.zwisler@linux.intel.com" <ross.zwisler@linux.intel.com>
Cc: "guangrong.xiao@gmail.com" <guangrong.xiao@gmail.com>,
"haozhong.zhang@intel.com" <haozhong.zhang@intel.com>,
"mst@redhat.com" <mst@redhat.com>,
"stefanha@gmail.com" <stefanha@gmail.com>,
"linux-nvdimm@lists.01.org" <linux-nvdimm@lists.01.org>,
"Knippers, Linda" <linda.knippers@hpe.com>,
"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
"imammedo@redhat.com" <imammedo@redhat.com>
Subject: Re: [Qemu-devel] QEMU NVDIMM as type 7 in e820 table
Date: Fri, 28 Jul 2017 20:19:15 +0000 [thread overview]
Message-ID: <1501272590.2042.91.camel@hpe.com> (raw)
In-Reply-To: <20170728194543.GA20726@linux.intel.com>
On Fri, 2017-07-28 at 13:45 -0600, Ross Zwisler wrote:
> On Fri, Jul 28, 2017 at 11:11:10AM -0700, Dan Williams wrote:
> > On Fri, Jul 28, 2017 at 11:04 AM, Ross Zwisler
> > <ross.zwisler@linux.intel.com> wrote:
:
> > Do you need that informationin e820? Linux effectively ignores
> > type-7. As long as the range is treated as reserved it's not clear
> > that you need the e820 entry. We also infect the persistent type
> > back into the memory map when the NFIT driver loads. /proc/iomem
> > should show the right data.
>
> [ Adding Linda & Toshi to see if they have an opinion. ]
>
> I guess maybe we don't need it. Yep, /proc/iomem looks good:
>
> # cat /proc/iomem
> 00000000-00000fff : Reserved
> 00001000-0009fbff : System RAM
> ...
> 100000000-23fffffff : System RAM
> 240000000-a3fffffff : Persistent Memory
> 240000000-a3fffffff : namespace0.0
>
> I was just worried that this was an inconsistency between the way
> that virtual NVDIMMs are presented vs the way that they will be
> presented on bare metal. I at least look at the e820 table to get my
> bearings of how memory is laid out - maybe I just need to look at
> /proc/iomem instead?
FW should present a persistent memory range in e820 or UEFI memory
descriptor table. So, it's a good practice for QEMU to do it as well.
That said, the NFIT driver inserts a persistent memory range to the
kernel IO resource table from NFIT, so we are OK without this info.
Yes, /proc/iomem shows how the resources are managed by the kernel.
Thanks,
-Toshi
next prev parent reply other threads:[~2017-07-28 20:19 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-07-28 18:04 [Qemu-devel] QEMU NVDIMM as type 7 in e820 table Ross Zwisler
2017-07-28 18:11 ` Dan Williams
2017-07-28 19:45 ` Ross Zwisler
2017-07-28 20:19 ` Dan Williams
2017-07-28 20:19 ` Kani, Toshimitsu [this message]
2017-07-29 10:49 ` Haozhong Zhang
2017-07-31 15:48 ` Ross Zwisler
2017-07-31 16:03 ` Igor Mammedov
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=1501272590.2042.91.camel@hpe.com \
--to=toshi.kani@hpe.com \
--cc=dan.j.williams@intel.com \
--cc=guangrong.xiao@gmail.com \
--cc=haozhong.zhang@intel.com \
--cc=imammedo@redhat.com \
--cc=linda.knippers@hpe.com \
--cc=linux-nvdimm@lists.01.org \
--cc=mst@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=ross.zwisler@linux.intel.com \
--cc=stefanha@gmail.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).