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 17:15:33 +0100 Message-ID: References: Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1625627110==" 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 Cc: xen-devel , Jan Beulich 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. --===============1625627110== Content-type: multipart/alternative; boundary="B_3269610933_25129830" > 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_3269610933_25129830 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable You mean that local_flush_tlb_one() is NOT executed the first time we try t= o map the FADT? That=B9s obviously bogus, since we have mapped other ACPI table= s in that fixmap entry earlier during boot, and this is evidenced by the fact that you can print out the current contents of that virtual address before calling __acpi_map_table() and you do not fault (which you would if the PTE did not have _PAGE_PRESENT set). So, now the investigation moves on to: WHY does map_pages_to_xen() think that the PTE was not present, when it quite obviously was?? I think we=B9re getting somewhere, albeit rather slowly :-) -- Keir On 10/8/07 17:11, "Stefan Berger" wrote: >> > The TLB handling looks correct though =8B if the modified PTE was not >> > previously empty then we execute an INVLPG on that virtual address. >> > Might be worth adding some tracing around there to see if the code >> > thinks the PTE was previously present, and hence whether the INVLPG >> > actually gets executed? >=20 > local_flush_tlb_one() does NOT get executed the first time, but upon the > second attempt.=20 > The mb() alone did NOT help. --B_3269610933_25129830 Content-type: text/html; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Re: [Xen-devel] [PATCH] [Xen] Check FADT's signature You m= ean that local_flush_tlb_one() is NOT executed the first time we try to map = the FADT? That’s obviously bogus, since we have mapped other ACPI tabl= es in that fixmap entry earlier during boot, and this is evidenced by the fa= ct that you can print out the current contents of that virtual address befor= e calling __acpi_map_table() and you do not fault (which you would if the PT= E did not have _PAGE_PRESENT set). So, now the investigation moves on to: WH= Y does map_pages_to_xen() think that the PTE was not present, when it quite = obviously was??

I think we’re getting somewhere, albeit rather slowly :-)

 -- Keir

On 10/8/07 17:11, "Stefan Berger" <stefanb@us.ibm.com> wrot= e:

> The TLB handling looks correct though — if the mod= ified PTE was not
> previously empty then we execute an INVLPG on that virtual address. > Might be worth adding some tracing around there to see if the code > thinks the PTE was previously present, and hence whether the INVLPG > actually gets executed? =

local_flush_tlb_one() does NOT get = executed the first time, but upon the second attempt.
The mb() alone did NOT help.=

--B_3269610933_25129830-- --===============1625627110== 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 --===============1625627110==--