WARNING - OLD ARCHIVES

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/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

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

To: Keir Fraser <Keir.Fraser@xxxxxxxxxxxx>
Subject: Re: [Xen-devel] [PATCH] [Xen] Check FADT's signature
From: Stefan Berger <stefanb@xxxxxxxxxx>
Date: Mon, 27 Aug 2007 06:50:47 -0400
Cc: xen-devel <xen-devel@xxxxxxxxxxxxxxxxxxx>, Jan Beulich <jbeulich@xxxxxxxxxx>
Delivery-date: Mon, 27 Aug 2007 04:02:13 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <C2F4B5C5.148C1%Keir.Fraser@xxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx

> Okay, please try tip of staging tree (c/s 15773).

This solves the problem with mapping ACPI memory and the timer address is read correctly. Thanks!

  Stefan

>
>  -- Keir
>
> On 24/8/07 07:19, "Stefan Berger" <stefanb@xxxxxxxxxx> wrote:

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