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

[Stefan Berger <stefanb@xxxxxxxxxx>]

Keir Fraser <keir@xxxxxxxxxxxxx> wrote on 08/10/2007
11:09:43 AM:

> Not by my reading of the code, but your testing shows differently
;-)
> 
> Have you tried adding tracing to map_pages_to_xen()? That’s the guts
> of the remapping code.

Now I did...

diff -r 7c5c3aa858cc xen/arch/x86/mm.c
--- a/xen/arch/x86/mm.c            
    Tue Jul 31 15:09:45 2007 +0100
+++ b/xen/arch/x86/mm.c            
    Fri Aug 10 11:21:49 2007 -0400
@@ -3539,6 +3539,7 @@ int map_pages_to_xen(
             nr_mfns -= 1UL;
         }
     }
+    local_flush_tlb_pge();
 
     return 0;
 }

This might be coarse but it does the trick to locate
the problem.

(XEN) (2) Mapped 0x3ffcfec0 to fff9bec0, base = 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 (10184kB)
(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) (2) Mapped 0x3ffcfec0 to fff9bec0, base = 0xfff9b000
(XEN) ACPI: PM-Timer IO Port: 0x588

success on first attempt :-)

(XEN) (2) Mapped 0x3ffcfd80 to fff9bd80, base = 0xfff9b000
(XEN) ACPI: ACPI SLEEP INFO: pm1x_cnt[584,0], pm1x_evt[580,0]
(XEN)                  wakeup_vec[3ffcfd8c],
vec_size[20]


(XEN) IN acpi_parse_fadt.
(XEN) Signature of acpi str. @ fff9bec0 before mapping: FACP„
(XEN) (2) Mapped 0x3ffcfec0 to fff9bec0, base = 0xfff9b000
(XEN) ACPI: PM-Timer IO Port: 0x588

   Stefan

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

> 
> Looking at the signature of the structure BEFORE the mapping happens
> (with hard coded address 0xfff9bec0)  shows the same signature
> before and after the mapping - at least on first try. 
> Hm, does the mapping code maybe not do the mapping again if it 
> thinks that the memory has already been mapped, but the code for 
> that testing has a bug? Otherwise a caching problem? 
> 
>  Stefan 
> 
> [...] 
> (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) (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) (2) Mapped 0x3ffcfec0 to fff9bec0, base = 0xfff9b000
> (XEN) ACPI: PM-Timer IO Port: 0x588
> 
> 
> (XEN) (2) Mapped 0x3ffcfd80 to fff9bd80, base = 0xfff9b000
> (XEN) ACPI: ACPI SLEEP INFO: pm1x_cnt[584,0], pm1x_evt[580,0]
> (XEN)                  wakeup_vec[3ffcfd8c],
vec_size[20]
> (XEN) IN acpi_parse_fadt.
> (XEN) Signature of acpi str. @ fff9bec0 before mapping: FACP„
> (XEN) (2) Mapped 0x3ffcfec0 to fff9bec0, base = 0xfff9b000
> (XEN) ACPI: PM-Timer IO Port: 0x588
> (XEN) (2) Mapped 0x3ffcfd80 to fff9bd80, base = 0xfff9b000
> (XEN) ACPI: ACPI SLEEP INFO: pm1x_cnt[584,0], pm1x_evt[580,0]
> (XEN)                  wakeup_vec[3ffcfd8c],
vec_size[20]
> (XEN) IN acpi_parse_fadt. 
> 
> 
> "Jan Beulich" <jbeulich@xxxxxxxxxx> wrote on 08/10/2007
04:51:57 AM:
> 
> > A TLB flushing issue (perhaps not even in software, as map_pages_to_xen()
> > appears to not have any problems in that respect)? Can you check
what
> > is at the offset into the mapped page after mapping the DSDT
(which is the
> > one place where the virtual page fff9bXXX gets associated with
a different
> > physical one; all other mappings map the same physical page),
but before
> > (re-)mapping the FADT? If that's not the data you observe, any
chance
> > you can find out (e.g. under native Linux) where the observed
data really
> > lives, to get an understanding where else such a broken translation
could
> > come from?
> > 
> > Jan
> > 
> > >>> Stefan Berger <stefanb@xxxxxxxxxx> 09.08.07
19:54 >>>
> > Keir Fraser <keir@xxxxxxxxxxxxx> wrote on 08/09/2007 09:33:01
AM:
> > 
> > > I'll wait for the real root cause to be discovered.
> > 
> > We have two blades of different type where we saw the problem
with the 
> > time going backwards. 
> > 
> > I used one of them to find out what is going on and where also
the 
> > previous xm dmesg dumps are coming. I gave that blade a BIOS
update two 
> > days ago. On this one Xen parsed the DSDT as the FADT (see posted
xm 
> > dmesg), but in the meantime this has corrected itself (no idea
what 
> > triggered this) and now the correct table is parsed and the correct
> > PM-Timer port is picked up - the same as Linux has found out.
So the first 
> > blade has become useless for this type of debugging.
> > 
> > The second blade is up-to-date in terms of BIOS and I even went
into the 
> > BIOS setup to give it a chance to maybe correct some things from
a 
> > previous update. On this one the allegded FADT's signature is
'A_AD' and a 
> > bogus timer port is still picked up there (0x4000 0837), while
Linux 
> > (2.6.20) gets the port right (0x588) as it seems.
> > 
> > 
> > On this second blade I now call the function parsing the fadt
multiple 
> > times, and here is what happens:
> > 
> > 
> > (XEN) System RAM: 1023MB (1047860kB)
> > (XEN) (1) Mapped 0xfdfc0 to ff0fdfc0
> > (XEN) ACPI: RSDP (v000 IBM          
                     
) @ 
> > 0x000fdfc0
> > (XEN) (2) Mapped 0x3ffcff80 to fff9bf80
> > (XEN) (2) Mapped 0x3ffcff80 to fff9bf80
> > (XEN) sdt_entry[0].pa = 0x3ffcfec0
> > (XEN) sdt_entry[1].pa = 0x3ffcfe00
> > (XEN) sdt_entry[2].pa = 0x3ffcfdc0
> > (XEN) sign: RSDT; name=RSDT0
> > (XEN) ACPI: RSDT (v001 IBM    SERBLADE 0x00001000 IBM
 0x45444f43) @ 
> > 0x3ffcff80
> > (XEN) (2) Mapped 0x3ffcfec0 to fff9bec0
> > (XEN) (2) Mapped 0x3ffcfec0 to fff9bec0
> > (XEN) sign: FACP; name=FADT
> > (XEN) ACPI: FADT (v002 IBM    SERBLADE 0x00001000 IBM
 0x45444f43) @ 
> > 0x3ffcfec0
> > (XEN) std_entry[0].id = 7,matches sign FACP
> > (XEN) (2) Mapped 0x3ffcfe00 to fff9be00
> > (XEN) (2) Mapped 0x3ffcfe00 to fff9be00
> > (XEN) sign: APIC; name=MADT
> > (XEN) ACPI: MADT (v001 IBM    SERBLADE 0x00001000 IBM
 0x45444f43) @ 
> > 0x3ffcfe00
> > (XEN) std_entry[1].id = 1,matches sign APIC
> > (XEN) (2) Mapped 0x3ffcfdc0 to fff9bdc0
> > (XEN) (2) Mapped 0x3ffcfdc0 to fff9bdc0
> > (XEN) sign: MCFG; name=MCFG<
> > (XEN) ACPI: MCFG (v001 IBM    SERBLADE 0x00001000 IBM
 0x45444f43) @ 
> > 0x3ffcfdc0
> > (XEN) std_entry[2].id = 18,matches sign MCFG
> > (XEN) (2) Mapped 0x3ffcfec0 to fff9bec0
> > (XEN) (2) Mapped 0x3ffbe4a8 to fff9b4a8
> > (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 (10184kB)
> > (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) (2) Mapped 0x3ffcfec0 to fff9bec0
> > (XEN) ACPI: Invalid FADT signature A__ADR
> > 
> > That one is bad. It has a bad signature! First call.
> > 
> > 
> > (XEN) (2) Mapped 0x3ffcfec0 to fff9bec0
> > (XEN) ACPI: PM-Timer IO Port: 0x588
> > 
> > 2nd call. This one is good! POrt is also good.
> > 
> > (XEN) (2) Mapped 0x3ffcfd80 to fff9bd80
> > (XEN) ACPI: ACPI SLEEP INFO: pm1x_cnt[584,0], pm1x_evt[580,0]
> > (XEN)                
 wakeup_vec[3ffcfd8c], vec_size[20]
> > (XEN) (2) Mapped 0x3ffcfec0 to fff9bec0
> > (XEN) ACPI: PM-Timer IO Port: 0x588
> > 
> > 3rd call. This one is also good!
> > 
> > Looks like the mapping does not work correctly.
> > 
> >    Stefan
> > 
> > > 
> > >  -- Keir
> > > 
> > > On 9/8/07 14:35, "Stefan Berger" <stefanb@xxxxxxxxxx>
wrote:
> > > 
> > > > Check the signature of the alleged FADT and only parse
it if it really
> > > > is the FADT and not something else. I understand that
this is not the
> > > > real solution, but prevents other bad things from happening,
like the
> > > > timer going backwards if a bogus PM-Timer port is picked
up.
> > > > 
> > > > Signed-off-by: Stefan Berger <stefanb@xxxxxxxxxx>
> > > > 
> > > > _______________________________________________
> > > > 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
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel