From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andrew Cooper Subject: Re: [PATCHv2] x86: map portion of kexec crash area that is within the direct map area Date: Thu, 9 Jan 2014 23:15:04 +0000 Message-ID: <52CF2D78.4@citrix.com> References: <1389206119-13527-1-git-send-email-david.vrabel@citrix.com> <20140109195038.GC3633@olila.local.net-space.pl> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <20140109195038.GC3633@olila.local.net-space.pl> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Daniel Kiper , David Vrabel Cc: Jan Beulich , Don Slutz , xen-devel@lists.xen.org List-Id: xen-devel@lists.xenproject.org On 09/01/2014 19:50, Daniel Kiper wrote: > By the way, why map_domain_page() behavior depends on debug option? > It is not nice because we could be trapped by this in the future in > more serious places. Could map_domain_page() work in the same way > with or without debug option? With a debug build of Xen, map_domain_page() always mutates the pagetables and hands out virtual addresses from the mapcache region. This is to test map_domain_page() itself, as well as making domain mapping leaks more obvious (as the mapcache is under heavier load). For a non-debug build of Xen, any map_domain_page() calls which can be satisfied by returning a virtual address from the direct map region (i.e. for pages below the 5TiB boundary which is basically all of them unless you have more money than sense) are, which avoided excessive use of the mapcache, and avoids a TLB shootdown/flush on unmap. ~Andrew