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

[Keir Fraser <keir@xensource.com>]

[-- Attachment #1.1: Type: text/plain, Size: 7520 bytes --]

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@us.ibm.com> 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_\b_ADR\f
> (XEN) (2) Mapped 0x3ffcfec0 to fff9bec0, base = 0xfff9b000
> (XEN) ACPI: Invalid FADT signature A_\b_ADR\f
> 
> 
> (XEN) IN acpi_parse_fadt.
> (XEN) Signature of acpi str. @ fff9bec0 before mapping: A_\b_ADR\f
> (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@novell.com> 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@us.ibm.com> 09.08.07 19:54 >>>
>> > Keir Fraser <keir@xensource.com> 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@us.ibm.com> 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@us.ibm.com>
>>>> > > > 
>>>> > > > _______________________________________________
>>>> > > > Xen-devel mailing list
>>>> > > > Xen-devel@lists.xensource.com
>>>> > > > http://lists.xensource.com/xen-devel
>>> > > 
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel



[-- Attachment #1.2: Type: text/html, Size: 10303 bytes --]

[-- Attachment #2: Type: text/plain, Size: 138 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel