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

[Keir Fraser <keir@xxxxxxxxxxxxx>]

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.

 -- 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