[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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




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

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.