This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Home Products Support Community News


Re: [Xen-devel] [PATCH] [Xen] Check FADT's signature

Yes, this seems to make things clear: paging_init() (re-)creates the page 
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 
(so it would seem to me that the code there could as well be removed).


>>> 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.


>  -- 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