From mboxrd@z Thu Jan 1 00:00:00 1970 From: Keir Fraser Subject: Re: [PATCH] [Xen] Check FADT's signature Date: Fri, 10 Aug 2007 16:09:43 +0100 Message-ID: References: Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0440817788==" Return-path: In-Reply-To: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Mime-version: 1.0 Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Stefan Berger , Jan Beulich Cc: xen-devel List-Id: xen-devel@lists.xenproject.org > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --===============0440817788== Content-type: multipart/alternative; boundary="B_3269606983_24873585" > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3269606983_24873585 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Not by my reading of the code, but your testing shows differently ;-) Have you tried adding tracing to map_pages_to_xen()? That=E2=80=99s the guts of t= he remapping code. -- Keir On 10/8/07 14:58, "Stefan Berger" wrote: >=20 > Looking at the signature of the structure BEFORE the mapping happens (wit= h > 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 tha= t the > memory has already been mapped, but the code for that testing has a bug? > Otherwise a caching problem? >=20 > Stefan=20 >=20 > [...]=20 > (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 >=20 >=20 > (XEN) IN acpi_parse_fadt. > (XEN) Signature of acpi str. @ fff9bec0 before mapping: A_=08_ADR=0C > (XEN) (2) Mapped 0x3ffcfec0 to fff9bec0, base =3D 0xfff9b000 > (XEN) ACPI: Invalid FADT signature A_=08_ADR=0C >=20 >=20 > (XEN) IN acpi_parse_fadt. > (XEN) Signature of acpi str. @ fff9bec0 before mapping: A_=08_ADR=0C > (XEN) (2) Mapped 0x3ffcfec0 to fff9bec0, base =3D 0xfff9b000 > (XEN) ACPI: PM-Timer IO Port: 0x588 >=20 >=20 > (XEN) (2) Mapped 0x3ffcfd80 to fff9bd80, base =3D 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=E2=80=9E > (XEN) (2) Mapped 0x3ffcfec0 to fff9bec0, base =3D 0xfff9b000 > (XEN) ACPI: PM-Timer IO Port: 0x588 > (XEN) (2) Mapped 0x3ffcfd80 to fff9bd80, base =3D 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. >=20 >=20 > "Jan Beulich" wrote on 08/10/2007 04:51:57 AM: >=20 >> > A TLB flushing issue (perhaps not even in software, as map_pages_to_xe= n() >> > 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 diffe= rent >> > physical one; all other mappings map the same physical page), but befo= re >> > (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 rea= lly >> > lives, to get an understanding where else such a broken translation co= uld >> > come from? >> >=20 >> > Jan >> >=20 >>>>> > >>> Stefan Berger 09.08.07 19:54 >>> >> > Keir Fraser wrote on 08/09/2007 09:33:01 AM: >> >=20 >>> > > I'll wait for the real root cause to be discovered. >> >=20 >> > We have two blades of different type where we saw the problem with the >> > time going backwards. >> >=20 >> > 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 tw= o >> > 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 f= irst >> > blade has become useless for this type of debugging. >> >=20 >> > The second blade is up-to-date in terms of BIOS and I even went into t= he >> > 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' a= nd a >> > bogus timer port is still picked up there (0x4000 0837), while Linux >> > (2.6.20) gets the port right (0x588) as it seems. >> >=20 >> >=20 >> > On this second blade I now call the function parsing the fadt multiple >> > times, and here is what happens: >> >=20 >> >=20 >> > (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 =3D 0x3ffcfec0 >> > (XEN) sdt_entry[1].pa =3D 0x3ffcfe00 >> > (XEN) sdt_entry[2].pa =3D 0x3ffcfdc0 >> > (XEN) sign: RSDT; name=3DRSDT0 >> > (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=3DFADT >> > (XEN) ACPI: FADT (v002 IBM SERBLADE 0x00001000 IBM 0x45444f43) @ >> > 0x3ffcfec0 >> > (XEN) std_entry[0].id =3D 7,matches sign FACP >> > (XEN) (2) Mapped 0x3ffcfe00 to fff9be00 >> > (XEN) (2) Mapped 0x3ffcfe00 to fff9be00 >> > (XEN) sign: APIC; name=3DMADT >> > (XEN) ACPI: MADT (v001 IBM SERBLADE 0x00001000 IBM 0x45444f43) @ >> > 0x3ffcfe00 >> > (XEN) std_entry[1].id =3D 1,matches sign APIC >> > (XEN) (2) Mapped 0x3ffcfdc0 to fff9bdc0 >> > (XEN) (2) Mapped 0x3ffcfdc0 to fff9bdc0 >> > (XEN) sign: MCFG; name=3DMCFG< >> > (XEN) ACPI: MCFG (v001 IBM SERBLADE 0x00001000 IBM 0x45444f43) @ >> > 0x3ffcfdc0 >> > (XEN) std_entry[2].id =3D 18,matches sign MCFG >> > (XEN) (2) Mapped 0x3ffcfec0 to fff9bec0 >> > (XEN) (2) Mapped 0x3ffbe4a8 to fff9b4a8 >> > (XEN) sign: DSDT; name=3DDSDT >> > (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 >> >=20 >> > That one is bad. It has a bad signature! First call. >> >=20 >> >=20 >> > (XEN) (2) Mapped 0x3ffcfec0 to fff9bec0 >> > (XEN) ACPI: PM-Timer IO Port: 0x588 >> >=20 >> > 2nd call. This one is good! POrt is also good. >> >=20 >> > (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 >> >=20 >> > 3rd call. This one is also good! >> >=20 >> > Looks like the mapping does not work correctly. >> >=20 >> > Stefan >> >=20 >>> > >=20 >>> > > -- Keir >>> > >=20 >>> > > On 9/8/07 14:35, "Stefan Berger" wrote: >>> > >=20 >>>> > > > 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 no= t the >>>> > > > real solution, but prevents other bad things from happening, lik= e the >>>> > > > timer going backwards if a bogus PM-Timer port is picked up. >>>> > > >=20 >>>> > > > Signed-off-by: Stefan Berger >>>> > > >=20 >>>> > > > _______________________________________________ >>>> > > > Xen-devel mailing list >>>> > > > Xen-devel@lists.xensource.com >>>> > > > http://lists.xensource.com/xen-devel >>> > >=20 >=20 >=20 > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xensource.com > http://lists.xensource.com/xen-devel --B_3269606983_24873585 Content-type: text/html; charset="UTF-8" Content-transfer-encoding: quoted-printable Re: [Xen-devel] [PATCH] [Xen] Check FADT's signature Not b= y 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> wrot= e:


Looking at the signature of the structure BEFORE the mapping happens (wit= h hard coded address 0xfff9bec0)  shows the same signature before and a= fter 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_=08_ADR=0C
(XEN) (2) Mapped 0x3ffcfec0 to fff9bec0, base =3D 0xfff9b000
(XEN) ACPI: Invalid FADT signature A_=08_ADR=0C


(XEN) IN acpi_parse_fadt.
(XEN) Signature of acpi str. @ fff9bec0 before mapping: A_=08_ADR=0C
(XEN) (2) Mapped 0x3ffcfec0 to fff9bec0, base =3D 0xfff9b000
(XEN) ACPI: PM-Timer IO Port: 0x588


(XEN) (2) Mapped 0x3ffcfd80 to fff9= bd80, base =3D 0xfff9b000
(XEN) ACPI: ACPI SLEEP INFO: pm1x_cnt[584,0], pm1x_evt[580,0]
(XEN)            &nb= sp;     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 =3D 0xfff9b000
(XEN) ACPI: PM-Timer IO Port: 0x588
(XEN) (2) Mapped 0x3ffcfd80 to fff9bd80, base =3D 0xfff9b000
(XEN) ACPI: ACPI SLEEP INFO: pm1x_cnt[584,0], pm1x_evt[580,0]
(XEN)            &nb= sp;     wakeup_vec[3ffcfd8c], vec_size[20]
(XEN) IN acpi_parse_fadt.

"Jan Beulich" <jbeulic= h@novell.com> wrote on 08/10/2007 04:51:57 AM:

> A TLB flushing issue (perhaps not even in software, as map_pages_to_xe= n()
> appears to not have any problems in that respect)? Can you check what<= BR> > 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 diffe= rent
> physical one; all other mappings map the same physical page), but befo= re
> (re-)mapping the FADT? If that's not the data you observe, any chance<= BR> > you can find out (e.g. under native Linux) where the observed data rea= lly
> lives, to get an understanding where else such a broken translation co= uld
> come from?
>
> Jan
>
> >>> Stefan Berger <stefanb@us.ibm.com> 09.08.07 19:54 &= gt;>>
> 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 tw= o
> days ago. On this one Xen parsed the DSDT as the FADT (see posted xm <= BR> > 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 f= irst
> 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 t= he
> 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' a= nd a
> bogus timer port is still picked up there (0x4000 0837), while Linux <= BR> > (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        &= nbsp;            = ;            ) @=
> 0x000fdfc0
> (XEN) (2) Mapped 0x3ffcff80 to fff9bf80
> (XEN) (2) Mapped 0x3ffcff80 to fff9bf80
> (XEN) sdt_entry[0].pa =3D 0x3ffcfec0
> (XEN) sdt_entry[1].pa =3D 0x3ffcfe00
> (XEN) sdt_entry[2].pa =3D 0x3ffcfdc0
> (XEN) sign: RSDT; name=3DRSDT0
> (XEN) ACPI: RSDT (v001 IBM    SERBLADE 0x00001000 IBM &= nbsp;0x45444f43) @
> 0x3ffcff80
> (XEN) (2) Mapped 0x3ffcfec0 to fff9bec0
> (XEN) (2) Mapped 0x3ffcfec0 to fff9bec0
> (XEN) sign: FACP; name=3DFADT
> (XEN) ACPI: FADT (v002 IBM    SERBLADE 0x00001000 IBM &= nbsp;0x45444f43) @
> 0x3ffcfec0
> (XEN) std_entry[0].id =3D 7,matches sign FACP
> (XEN) (2) Mapped 0x3ffcfe00 to fff9be00
> (XEN) (2) Mapped 0x3ffcfe00 to fff9be00
> (XEN) sign: APIC; name=3DMADT
> (XEN) ACPI: MADT (v001 IBM    SERBLADE 0x00001000 IBM &= nbsp;0x45444f43) @
> 0x3ffcfe00
> (XEN) std_entry[1].id =3D 1,matches sign APIC
> (XEN) (2) Mapped 0x3ffcfdc0 to fff9bdc0
> (XEN) (2) Mapped 0x3ffcfdc0 to fff9bdc0
> (XEN) sign: MCFG; name=3DMCFG<
> (XEN) ACPI: MCFG (v001 IBM    SERBLADE 0x00001000 IBM &= nbsp;0x45444f43) @
> 0x3ffcfdc0
> (XEN) std_entry[2].id =3D 18,matches sign MCFG
> (XEN) (2) Mapped 0x3ffcfec0 to fff9bec0
> (XEN) (2) Mapped 0x3ffbe4a8 to fff9b4a8
> (XEN) sign: DSDT; name=3DDSDT
> (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)           &nbs= p;      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 i= s 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/x= en-devel

 --B_3269606983_24873585-- --===============0440817788== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel --===============0440817788==--