All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Jan Beulich" <jbeulich@novell.com>
To: Keir Fraser <Keir.Fraser@cl.cam.ac.uk>,
	Stefan Berger <stefanb@us.ibm.com>
Cc: xen-devel <xen-devel@lists.xensource.com>
Subject: Re: [PATCH] [Xen] Check FADT's signature
Date: Fri, 24 Aug 2007 08:13:15 +0100	[thread overview]
Message-ID: <46CEA12B.76E4.0078.0@novell.com> (raw)
In-Reply-To: <OF5D8667A8.2C8B815F-ON85257341.0021DF5D-C1257341.0022C63B@us.ibm.com>

Yes, this seems to make things clear: paging_init() (re-)creates the page directory
for the ioremap area, which was partially established already by set_fixmap()/
map_pages_to_xen(). While adding a check there seems trivial I wonder what
the purpose of this initialization is, given that there's no (real) ioremap anyway
(so it would seem to me that the code there could as well be removed).

Jan

>>> Stefan Berger <stefanb@us.ibm.com> 24.08.07 08:19 >>>
xen-devel-bounces@lists.xensource.com wrote on 08/10/2007 09:15:57 PM:

> A good debugging approach will be to write a function that walks the
> pagetables for that virtual address and prints the PTE that maps it.
> Scatter calls to this function between acpi_boot_table_init() and 
> acpi_boot_init() and hence narrow down exactly where the PTE is 
> getting zapped.

What is happening is that the pl1e pointer used for mapping the ACPI table 
entry changes between the calls before paging_init() and after. The 
l1_pgentry_t that is used before paging_init() correctly shows that the 
page is present whereas the one used after indicates that the page is not 
present. Then when the ACPI table is mapped after paging_init() the tlb is 
not flushed and wrong information is read.

   Stefan

> 
>  -- Keir
> 
> On 10/8/07 19:21, "Keir Fraser" <keir@xensource.com> wrote:

> On 10/8/07 18:00, "Stefan Berger" <stefanb@us.ibm.com> wrote:

> (XEN) map_pages_to_xen : 3533 
> (that's the line number)
> (XEN) 0xfff9b000 was NOT present. 
> 
> Something between (*) and here seems to trash this presence flag. 
> paging_init() and many others lie in between the upper call and this
> one here. Could be a side effect of this? Maybe that tlb flush at 
> the right place in one of these functions would solve the problem? 
> 
> Yes, this now looks likely and that?s rather scary. We?ll go after 
> this next week.
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com 
> http://lists.xensource.com/xen-devel

  reply	other threads:[~2007-08-24  7:13 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-08-09 13:35 [PATCH] [Xen] Check FADT's signature Stefan Berger
2007-08-09 13:33 ` Keir Fraser
2007-08-09 17:54   ` Stefan Berger
2007-08-10  6:55     ` Keir Fraser
2007-08-10 11:36       ` Stefan Berger
2007-08-10 13:23         ` Keir Fraser
2007-08-10  8:51     ` Jan Beulich
2007-08-10 13:58       ` Stefan Berger
2007-08-10 15:09         ` Keir Fraser
2007-08-10 15:35           ` Stefan Berger
2007-08-10 15:58             ` Keir Fraser
2007-08-10 16:11               ` Stefan Berger
2007-08-10 16:15                 ` Keir Fraser
2007-08-10 17:00                   ` Stefan Berger
2007-08-10 18:21                     ` Keir Fraser
2007-08-10 19:15                       ` Keir Fraser
2007-08-24  6:19                         ` Stefan Berger
2007-08-24  7:13                           ` Jan Beulich [this message]
2007-08-24 15:04                             ` Keir Fraser
2007-08-24 15:20                           ` Keir Fraser
2007-08-27 10:50                             ` Stefan Berger

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=46CEA12B.76E4.0078.0@novell.com \
    --to=jbeulich@novell.com \
    --cc=Keir.Fraser@cl.cam.ac.uk \
    --cc=stefanb@us.ibm.com \
    --cc=xen-devel@lists.xensource.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.