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

To: Jan Beulich <jbeulich@xxxxxxxxxx>, Stefan Berger <stefanb@xxxxxxxxxx>
Subject: Re: [Xen-devel] [PATCH] [Xen] Check FADT's signature
From: Keir Fraser <Keir.Fraser@xxxxxxxxxxxx>
Date: Fri, 24 Aug 2007 16:04:22 +0100
Cc: xen-devel <xen-devel@xxxxxxxxxxxxxxxxxxx>
Delivery-date: Fri, 24 Aug 2007 08:05:34 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <46CEA12B.76E4.0078.0@xxxxxxxxxx>
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
Thread-index: AcfmYA1vTCsaplJTEdyesQAX8io7RQ==
Thread-topic: [Xen-devel] [PATCH] [Xen] Check FADT's signature
User-agent: Microsoft-Entourage/
The area is also used by domain_page.c routines.


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