Date: Tue, 4 Nov 2014 10:46:28 +0200 From: Konstantin Belousov <kostikbel@gmail.com> To: John Baldwin <jhb@freebsd.org> Cc: freebsd-amd64@freebsd.org Subject: Re: memory type e820 Message-ID: <20141104084628.GN53947@kib.kiev.ua> In-Reply-To: <3381641.WgZAz21Lfu@pippin.baldwin.cx> References: <CABv3qbEuggLT=9vsHAs5Rdp8a0V-=DG7DnPO1BQk4Ghn4r_9Dw@mail.gmail.com> <201410301353.05185.jhb@freebsd.org> <CABv3qbHQEFZiQ4p%2BHWZNLt0MiNnHBmDW1aTFhWB7vhr4J3BGfQ@mail.gmail.com> <3381641.WgZAz21Lfu@pippin.baldwin.cx>
index | next in thread | previous in thread | raw e-mail
On Mon, Nov 03, 2014 at 01:52:44PM -0500, John Baldwin wrote: > On Saturday 01 November 2014 18:55:53 Sourish Mazumder wrote: > > Hi John, > > > > I tried the pmap_mapdev() as suggested by you. Works perfectly. Thanks for > > the information. > > Sure. > > > What is required, If I want to add this nvram memory to VM pages? > > Hmm. If this is device memory you generally don't want that. I'm not > actually sure how to do this at runtime. If you don't mind having a local > hack you can add a change in the MD startup code (e.g. in hammer_time() > in sys/amd64/amd64/machdep.c) to adjust the ranges added to > phys_avail[] and dump_avail[]. The facility exists to do this. It is OBJT_MGTDEVICE pager and vm_phys_fictitious_reg_range(). This is used by i915 and TTM for aperture, and seems XEN dom0 code uses it for mapping pages from other domains into dom0.home | help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20141104084628.GN53947>