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

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


  • To: Stefan Berger <stefanb@xxxxxxxxxx>
  • From: Keir Fraser <keir@xxxxxxxxxxxxx>
  • Date: Fri, 10 Aug 2007 17:15:33 +0100
  • Cc: xen-devel <xen-devel@xxxxxxxxxxxxxxxxxxx>, Jan Beulich <jbeulich@xxxxxxxxxx>
  • Delivery-date: Fri, 10 Aug 2007 09:16:11 -0700
  • List-id: Xen developer discussion <xen-devel.lists.xensource.com>
  • Thread-index: Acfbaa1d66XdUkdcEdy2zAAX8io7RQ==
  • Thread-topic: [Xen-devel] [PATCH] [Xen] Check FADT's signature

You mean 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 tables 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’re getting somewhere, albeit rather slowly :-)

 -- Keir

On 10/8/07 17:11, "Stefan Berger" <stefanb@xxxxxxxxxx> wrote:

> The TLB handling looks correct though — 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?


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

_______________________________________________
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®.