[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH] [Xen] Check FADT's signature
The area is also used by domain_page.c routines. K. On 24/8/07 08:13, "Jan Beulich" <jbeulich@xxxxxxxxxx> wrote: > 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 <stefanb@xxxxxxxxxx> 24.08.07 08:19 >>> > xen-devel-bounces@xxxxxxxxxxxxxxxxxxx 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 >> acpi_boot_init() and hence narrow down exactly where the PTE is >> getting zapped. > > What is happening is that the pl1e pointer used for mapping the ACPI table > entry changes between the calls before paging_init() and after. The > l1_pgentry_t that is used before paging_init() correctly shows that the > page is present whereas the one used after indicates that the page is not > present. Then when the ACPI table is mapped after paging_init() the tlb is > not flushed and wrong information is read. > > Stefan > >> >> -- Keir >> >> On 10/8/07 19:21, "Keir Fraser" <keir@xxxxxxxxxxxxx> wrote: > >> On 10/8/07 18:00, "Stefan Berger" <stefanb@xxxxxxxxxx> wrote: > >> (XEN) map_pages_to_xen : 3533 >> (that's the line number) >> (XEN) 0xfff9b000 was NOT present. >> >> Something between (*) and here seems to trash this presence flag. >> 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 >> the right place in one of these functions would solve the problem? >> >> Yes, this now looks likely and that?s rather scary. We?ll go after >> this next week. >> _______________________________________________ >> Xen-devel mailing list >> Xen-devel@xxxxxxxxxxxxxxxxxxx >> http://lists.xensource.com/xen-devel > _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxx http://lists.xensource.com/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |