From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Jan Beulich" Subject: Re: [PATCH] [Xen] Check FADT's signature Date: Fri, 24 Aug 2007 08:13:15 +0100 Message-ID: <46CEA12B.76E4.0078.0@novell.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable 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: Keir Fraser , Stefan Berger Cc: xen-devel List-Id: xen-devel@lists.xenproject.org Yes, this seems to make things clear: paging_init() (re-)creates the page = directory for the ioremap area, which was partially established already by set_fixmap= ()/ map_pages_to_xen(). While adding a check there seems trivial I wonder what the purpose of this initialization is, given that there's no (real) = ioremap anyway (so it would seem to me that the code there could as well be removed). Jan >>> Stefan Berger 24.08.07 08:19 >>> xen-devel-bounces@lists.xensource.com wrote on 08/10/2007 09:15:57 PM: > A good debugging approach will be to write a function that walks the > pagetables for that virtual address and prints the PTE that maps it. > Scatter calls to this function between acpi_boot_table_init() and=20 > acpi_boot_init() and hence narrow down exactly where the PTE is=20 > getting zapped. What is happening is that the pl1e pointer used for mapping the ACPI = table=20 entry changes between the calls before paging_init() and after. The=20 l1_pgentry_t that is used before paging_init() correctly shows that the=20 page is present whereas the one used after indicates that the page is = not=20 present. Then when the ACPI table is mapped after paging_init() the tlb = is=20 not flushed and wrong information is read. Stefan >=20 > -- Keir >=20 > On 10/8/07 19:21, "Keir Fraser" wrote: > On 10/8/07 18:00, "Stefan Berger" wrote: > (XEN) map_pages_to_xen : 3533=20 > (that's the line number) > (XEN) 0xfff9b000 was NOT present.=20 >=20 > Something between (*) and here seems to trash this presence flag.=20 > paging_init() and many others lie in between the upper call and this > one here. Could be a side effect of this? Maybe that tlb flush at=20 > the right place in one of these functions would solve the problem?=20 >=20 > Yes, this now looks likely and that?s rather scary. We?ll go after=20 > this next week. > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xensource.com=20 > http://lists.xensource.com/xen-devel