Date: Tue, 18 Apr 2017 16:45:56 +0300 From: Konstantin Belousov <kostikbel@gmail.com> To: Dexuan Cui <decui@microsoft.com> Cc: "src-committers@freebsd.org" <src-committers@freebsd.org>, "svn-src-all@freebsd.org" <svn-src-all@freebsd.org>, "svn-src-head@freebsd.org" <svn-src-head@freebsd.org>, Sepherosa Ziehau <sephe@freebsd.org>, Hongjiang Zhang <honzhan@microsoft.com> Subject: Re: svn commit: r316767 - head/sys/amd64/amd64 Message-ID: <20170418134556.GY1788@kib.kiev.ua> In-Reply-To: <HK2P15301MB00033BEA7B656EBCD3BDFC5CBF190@HK2P15301MB0003.APCP153.PROD.OUTLOOK.COM> References: <201704131549.v3DFnt9I004050@repo.freebsd.org> <HK2P15301MB00033BEA7B656EBCD3BDFC5CBF190@HK2P15301MB0003.APCP153.PROD.OUTLOOK.COM>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, Apr 18, 2017 at 12:41:09PM +0000, Dexuan Cui wrote: > > From: owner-svn-src-head@freebsd.org [mailto:owner-svn-src- > > head@freebsd.org] On Behalf Of Konstantin Belousov > > Sent: Thursday, April 13, 2017 23:50 > > > > Author: kib > > Date: Thu Apr 13 15:49:55 2017 > > New Revision: 316767 > > URL: > > > > Log: > > Map DMAP as nx. > > > > Demotions preserve PG_NX, so it is enough to set nx bit for initial > > lowest-level paging entries. > > > > Modified: > > head/sys/amd64/amd64/pmap.c > > Hi kib, > Unluckily this patch breaks Hyper-V VM: > > In dev/hyperv/vmbus/hyperv.c: hypercall_create() we allocate one > page and pass its physical address to the hypervisor, which initializes > the page with executable code. > > Later in dev/hyperv/vmbus/hyperv.c: hypercall_post_message(), we > "call" the executable code in the above page. > > Now with NX, the "call" gets a fault and as a result FreeBSD VM > can't boot on Hyper-V. > > It looks memory allocated by bus_dmamem_alloc() and malloc() > is not executable now. > > What else can we use? > I guess we can only use contigmalloc() or kmem_malloc() to > get a page that can be executable and use vtophys() to get its > physical address? Yes, the kmem_malloc() is considered to be a suitable substitution for regular malloc(9) if the executable mapping is needed. See r317072 for a similar fix for the same issue.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20170418134556.GY1788>