From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Suresh Siddha <suresh.b.siddha@intel.com>
Cc: "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"hpa@zytor.com" <hpa@zytor.com>,
"rostedt@goodmis.org" <rostedt@goodmis.org>,
"jeremy@goop.org" <jeremy@goop.org>
Subject: Re: [LKML] Re: [PATCH] x86_64: allow sections that are recycled to set _PAGE_RW
Date: Tue, 16 Feb 2010 17:13:13 -0500 [thread overview]
Message-ID: <20100216221313.GA22869@phenom.dumpdata.com> (raw)
In-Reply-To: <1266091697.2677.64.camel@sbs-t61>
On Sat, Feb 13, 2010 at 12:08:17PM -0800, Suresh Siddha wrote:
> Konrad,
>
> I don't think this patch is correct.
>
> I am not sure if I understand why we see this failure in Xen. In native
> case, we have two kernel mappings for 64bit kernel.
>
> One is kernel text mapping:
>
> ffffffff80000000 - ffffffffa0000000 (=512 MB) kernel text mapping, from
> phys 0
>
> And another is:
>
> ffff880000000000 - ffffc7ffffffffff (=64 TB) direct mapping of all phys.
> memory
>
> Checks in static_protections() ensure that we map the text mapping as
> read-only (and don't bother about what permissions it uses for
> underlying free pages that get freed in free_init_pages()). But the
> kernel direct mappings for free pages will be RW and ensure that the
> free pages can be read/written using the direct mapping.
>
> The checks in static_protections() for kernel text mapping ensure that
> we don't break the 2MB kernel text pages unnecessarily on 64bit kernels
> (as it has performance implications). We should be fine as long as the
> kernel identity mappings reflect the correct RW permissions.
>
> But somehow this is working fine on native kernels but not on Xen pv
> guest. Your patch will cause the performance issues that we are
That would not be good.
> addressing using the static protections checks. I will look at this more
> detailed on tuesday.
Great. Thank you for doing that. If you find yourself in a bind, here are
some steps on how to build the Xen pv-ops kernel and such:
http://wiki.xensource.com/xenwiki/XenParavirtOps
It goes without saying that I would be happy to test your patch when
you have one ready.
next prev parent reply other threads:[~2010-02-16 22:29 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-02-13 3:15 [PATCH] fix BUG: unable to handle kernel .. in free_init_pages called from mark_rodata_ro Konrad Rzeszutek Wilk
2010-02-13 3:15 ` [PATCH] x86_64: allow sections that are recycled to set _PAGE_RW Konrad Rzeszutek Wilk
2010-02-13 20:08 ` Suresh Siddha
2010-02-14 5:12 ` H. Peter Anvin
2010-02-16 22:13 ` Konrad Rzeszutek Wilk [this message]
2010-02-18 19:51 ` [LKML] " Suresh Siddha
2010-02-22 23:48 ` [tip:x86/urgent] x86_64, cpa: Don't work hard in preserving kernel 2M mappings when using 4K already tip-bot for Suresh Siddha
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=20100216221313.GA22869@phenom.dumpdata.com \
--to=konrad.wilk@oracle.com \
--cc=hpa@zytor.com \
--cc=jeremy@goop.org \
--cc=linux-kernel@vger.kernel.org \
--cc=rostedt@goodmis.org \
--cc=suresh.b.siddha@intel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).