From mboxrd@z Thu Jan 1 00:00:00 1970 From: Keir Fraser Subject: Re: [PATCH 6/8] xen/debug: WARN_ON when 1-1 but no _PAGE_IOMAP flag set. Date: Thu, 06 Jan 2011 22:17:06 +0000 Message-ID: References: <20110106215952.GB18722@dumpdata.com> Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <20110106215952.GB18722@dumpdata.com> Sender: linux-kernel-owner@vger.kernel.org To: Konrad Rzeszutek Wilk Cc: Stefano Stabellini , Ian Campbell , "linux-kernel@vger.kernel.org" , Jeremy Fitzhardinge , "hpa@zytor.com" , Jan Beulich , "xen-devel@lists.xensource.com" , Konrad Rzeszutek Wilk List-Id: xen-devel@lists.xenproject.org On 06/01/2011 21:59, "Konrad Rzeszutek Wilk" wrote: >> Always 0x55...55 (for m2p entries that exist), else page fault on access to >> the non-existent m2p entry (m2p entries only guaranteed to exist for ram). >> Perhaps the 0xff...ff values come from Linux's own fixup code handling a >> faulting read access of the m2p array? If so you could return 0x55...55 >> instead and avoid checking for 0xff...ff. I really don't know how you could >> get 0xff...ff for non-RAM pages from Xen itself. > > The non-RAM pages are assinged to a DOMID_IO (arch_init_memory), for example: > > 298 /* First 1MB of RAM is historically marked as I/O. */ > 299 for ( i = 0; i < 0x100; i++ ) > 300 share_xen_page_with_guest(mfn_to_page(i), dom_io, > XENSHARE_writable); > > and share_xen_page.. sets that page to INVALID_M2P_ENTRY. > > But I could also be reading the code wrongly? You're right, I missed that. -- Keir