From: Keir Fraser <keir@xensource.com>
To: Stefan Berger <stefanb@us.ibm.com>
Cc: xen-devel <xen-devel@lists.xensource.com>,
Jan Beulich <jbeulich@novell.com>
Subject: Re: [PATCH] [Xen] Check FADT's signature
Date: Fri, 10 Aug 2007 17:15:33 +0100 [thread overview]
Message-ID: <C2E24DB5.1404F%keir@xensource.com> (raw)
In-Reply-To: <OF4092ECA3.280FC95E-ON85257333.0058A1FB-85257333.0058E718@us.ibm.com>
[-- Attachment #1.1: Type: text/plain, Size: 1156 bytes --]
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@us.ibm.com> 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.
[-- Attachment #1.2: Type: text/html, Size: 1864 bytes --]
[-- Attachment #2: Type: text/plain, Size: 138 bytes --]
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
next prev parent reply other threads:[~2007-08-10 16:15 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 [this message]
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
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=C2E24DB5.1404F%keir@xensource.com \
--to=keir@xensource.com \
--cc=jbeulich@novell.com \
--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.