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

[Stefan Berger <stefanb@xxxxxxxxxx>]

xen-devel-bounces@xxxxxxxxxxxxxxxxxxx wrote on 08/10/2007
12:15:33 PM:

> You mean that local_flush_tlb_one() is NOT executed the first time
> we try to map the FADT? That’s obviously bogus, since we have mapped
> other ACPI tables in that fixmap entry earlier during boot, and this
> is evidenced by the fact that you can print out the current contents
> of that virtual address before calling __acpi_map_table() and you
do
> not fault (which you would if the PTE did not have _PAGE_PRESENT 
> set). So, now the investigation moves on to: WHY does 
> map_pages_to_xen() think that the PTE was not present, when it quite
> obviously was??


(XEN) local_flush_tlb_one(0xfff9b000)
(XEN) (2) Mapped 0x3ffcfec0 to fff9bec0, base = 0xfff9b000
(XEN) map_pages_to_xen : 3533
(XEN) local_flush_tlb_one(0xfff9b000)

(*)

(XEN) (2) Mapped 0x3ffbe4a8 to fff9b4a8, base = 0xfff9b000
(XEN) sign: DSDT; name=DSDT
(XEN) ACPI: DSDT (v001 IBM    SERBLADE 0x00001000 INTL 0x02002025)
@ 0x00000000
(XEN) NUMA turned off
(XEN) Faking a node at 0000000000000000-000000003ffb0000
(XEN) Xen heap: 9MB (10200kB)
(XEN) Domain heap initialised: DMA width 32 bits
(XEN) PAE enabled, limit: 16 GB
(XEN) found SMP MP-table at 0009d540
(XEN) DMI 2.3 present.
(XEN) (1) Mapped 0xf601f to ff0f601f
(XEN) Using APIC driver default
(XEN) IN acpi_parse_fadt.
(XEN) Signature of acpi str. @ fff9bec0 before mapping: A__ADR
(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?

(XEN) (2) Mapped 0x3ffcfec0 to fff9bec0, base = 0xfff9b000
(XEN) ACPI: Invalid FADT signature A__ADR
(XEN) IN acpi_parse_fadt.
(XEN) Signature of acpi str. @ fff9bec0 before mapping: A__ADR
(XEN) map_pages_to_xen : 3533
(XEN) local_flush_tlb_one(0xfff9b000)

Assumed to be present here...

(XEN) (2) Mapped 0x3ffcfec0 to fff9bec0, base = 0xfff9b000
(XEN) ACPI: PM-Timer IO Port: 0x588
(XEN) map_pages_to_xen : 3533

> 
> I think we’re getting somewhere, albeit rather slowly :-)

Yes, slow apprentice and now he's has to take off.
:-) 
 
Cheers!

  Stefan
> 
>  -- Keir
> 
> On 10/8/07 17:11, "Stefan Berger" <stefanb@xxxxxxxxxx>
wrote:

> > The TLB handling looks correct though —
if the modified PTE was not 
> > previously empty then we execute an INVLPG on that virtual address.
> > Might be worth adding some tracing around there to see if the
code 
> > thinks the PTE was previously present, and hence whether the
INVLPG 
> > actually gets executed? 
> 
> local_flush_tlb_one() does NOT get executed the first time, but upon
> the second attempt. 
> The mb() alone did NOT help. 
> _______________________________________________
> 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