Re: QEMU NVDIMM as type 7 in e820 table

["Kani, Toshimitsu" <toshi.kani@hpe.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
_______________________________________________
Linux-nvdimm mailing list
Linux-nvdimm@lists.01.org
https://lists.01.org/mailman/listinfo/linux-nvdimm