From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Jan Beulich" Subject: Re: Linux: PG_pinned vs. PG_foreign Date: Mon, 15 Jan 2007 11:36:09 +0000 Message-ID: <45AB7539.76E4.0078.0@novell.com> References: <45AB59A9.76E4.0078.0@novell.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: Content-Disposition: inline List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: xen-devel@lists.xensource.com, Keir Fraser List-Id: xen-devel@lists.xenproject.org >>> Keir Fraser 15.01.07 11:10 >>> >On 15/1/07 09:38, "Jan Beulich" wrote: > >> Is it intentional that these two both use PG_arch_1? It seems at least risky >> to me... And if intended, it would certainly deserve a comment. (I was about >> to utilize PG_pinned for indicating pinned highmem-allocated PTEs when I >> realized this collision.) > >There's no reason to have them use the same bit if there's a PG_arch_2 >available. It was probbaly laziness on my part when I realised that (so far) >ForeignPage and Pinned are mutually exclusive. There isn't, but there are a few bits left, so that shouldn't be a problem. PG_foreign really should be a standalone one, not using PR_arch_1, as arches may have or get a meaning assigned for this (ia64 specifically has), so even if it isn't a problem today it is very much like a latent bug. I'll try to send a respective patch soon, but since I want to use this in our code, too, I first have to resolve a collision with s390 patches from IBM, which consume all the remaining bit positions. Jan