From mboxrd@z Thu Jan 1 00:00:00 1970 From: Rik van Riel Subject: Re: invalid PTE for xen_start-info ? Date: Wed, 04 Oct 2006 09:47:15 -0400 Message-ID: <4523BB63.5000005@redhat.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Keir Fraser Cc: "xen-devel@lists.xensource.com" List-Id: xen-devel@lists.xenproject.org Keir Fraser wrote: > On 3/10/06 7:06 pm, "Rik van Riel" wrote: > >> pte 0000000019800027 (real 0010000035010027) >> >> That last PTE value does not look like a valid x86-64 PTE >> value to me. That high bit is not the NX bit, nor is it >> within the physical address range of the system in question. >> >> What's going on here? >> >> Is this a bug you would like a fix for? > > It's not a bug -- it's one of the available-for-software flags that is > stolen by Xen to indicate a kernel PTE. This is done so that we can > distinguish kernel and user mappings, so that the latter can have the global > bit set. Sounds weird, but it avoids flushing user mappings from the TLB > when executing syscalls (we have to change %cr3 value when switching between > guest-user and guest-kernel modes). OK, so pte_val() just needs to know about these software flags and mask them out before passing the value to mfn_to_pfn ? -- "You don't have to be crazy to do this... but it helps." -- Bob Ross