|
|
|
|
|
|
|
|
|
|
xen-devel
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
|
<Prev in Thread] |
Current Thread |
[Next in Thread>
|
- Re: [Xen-devel] [PATCH] [Xen] Check FADT's signature, (continued)
- Re: [Xen-devel] [PATCH] [Xen] Check FADT's signature, Keir Fraser
- Re: [Xen-devel] [PATCH] [Xen] Check FADT's signature, Stefan Berger
- Re: [Xen-devel] [PATCH] [Xen] Check FADT's signature, Keir Fraser
- Re: [Xen-devel] [PATCH] [Xen] Check FADT's signature, Stefan Berger
- Re: [Xen-devel] [PATCH] [Xen] Check FADT's signature, Keir Fraser
- Re: [Xen-devel] [PATCH] [Xen] Check FADT's signature, Stefan Berger
- Re: [Xen-devel] [PATCH] [Xen] Check FADT's signature, Keir Fraser
- Re: [Xen-devel] [PATCH] [Xen] Check FADT's signature, Keir Fraser
- Re: [Xen-devel] [PATCH] [Xen] Check FADT's signature, Stefan Berger
- Re: [Xen-devel] [PATCH] [Xen] Check FADT's signature, Jan Beulich
- Re: [Xen-devel] [PATCH] [Xen] Check FADT's signature,
Keir Fraser <=
- Re: [Xen-devel] [PATCH] [Xen] Check FADT's signature, Keir Fraser
- Re: [Xen-devel] [PATCH] [Xen] Check FADT's signature, Stefan Berger
|
|
|
|
|