From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: linux-kernel@vger.kernel.org, jeremy@goop.org, hpa@zytor.com
Cc: Jan Beulich <JBeulich@novell.com>,
xen-devel@lists.xensource.com,
Konrad Rzeszutek Wilk <konrad@kernel.org>
Subject: [RFC PATCH v1] Consider void entries in the P2M as 1-1 mapping.
Date: Tue, 21 Dec 2010 16:37:30 -0500 [thread overview]
Message-ID: <1292967460-15709-1-git-send-email-konrad.wilk@oracle.com> (raw)
Please see attached an RFC of first set of patches that augments
how Xen MMU deals with PFNs that point to physical devices.
Short summary: No need to troll through code to add VM_IO on mmap paths
anymore.
Long summary:
Under Xen MMU we would distinguish two different types of PFNs in
the P2M tree: real MFN, INVALID_P2M_ENTRY (missing PFN - used for ballooning).
If there was a device which PCI BAR was within the P2M, we would look
at the flags and if _PAGE_IOMAP was passed we would just return the PFN without
consulting the P2M. We have a patch (and some auxilary for other subsystems)
that sets this:
x86: define arch_vm_get_page_prot to set _PAGE_IOMAP on VM_IO vmas
This patchset proposes a different way of doing this where the patch
above and the other auxilary ones will not be neccessary.
This different is the one that H. Peter Anvin and Jeremy Fitzhardinge
suggested. The mechanism is to think of the void entries (so not filled) in the
P2M tree structure as identity (1-1) mapping. In the past we used to think of
those regions as "missing" and under the ownership of the balloon code. But
the balloon code only operates on a specific region. This region is in last
E820 RAM page (basically any region past nr_pages is considered balloon
type page).
Gaps in the E820 (which are usually considered to PCI BAR spaces) would end up
with the void entries and point to the "missing" pages.
This patchset considers the void entries as "identity" and for balloon pages
you have to set the PFNs to be "missing". This means that the void entries
are now considered 1-1, so for PFNs which exist in large gaps of the P2M space
will return the same PFN. Since the E820 gaps could cross boundary (keep in
mind that the P2M structure is a 3-level tree) in the P2M regions we go
through the E820 gaps and reserved E820 regions and set those to be
identity. For large regions we just hook up the top (or middle) pointer
to shared "identity" pages. For smaller regions we set the MFN wherein
pfn_to_mfn(pfn)==pfn.
For the case of the balloon pages, the setting of the "missing" pages
is mostly already done. The initial case of carving the last E820 region for
balloon ownership is augmented to set those PFNs to missing.
This patchset is also available under git:
git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git devel/p2m-identity
Further work:
The xen/mmu.c code where it deals with _PAGE_IOMAP can be removed, but
to guard against regressions or bugs lets take it one patchset at a time.
Also filter out _PAGE_IOMAP on entries that are System RAM (which is wrong).
With this P2M to lookup we can make this determination easily.
P.S.
You might wonder why the IDENTITY_P2M_ENTRY value is not used when writting
to the P2M, but only used as flag. That is b/c the toolset does not consider
that value to be correct so instead we use the INVALID_P2M_ENTRY.
In-Reply-To:
next reply other threads:[~2010-12-21 21:37 UTC|newest]
Thread overview: 38+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-12-21 21:37 Konrad Rzeszutek Wilk [this message]
2010-12-21 21:37 ` [PATCH 01/10] xen: Make all reserved pages for the balloon be INVALID_P2M_ENTRY Konrad Rzeszutek Wilk
2010-12-21 22:19 ` Jeremy Fitzhardinge
2010-12-21 23:22 ` H. Peter Anvin
2010-12-22 8:47 ` Ian Campbell
2010-12-22 14:53 ` Konrad Rzeszutek Wilk
2010-12-22 15:46 ` Jeremy Fitzhardinge
2010-12-21 21:37 ` [PATCH 02/10] xen/p2m: change p2m_missing_* to p2m_identity_* Konrad Rzeszutek Wilk
2010-12-21 22:41 ` Jeremy Fitzhardinge
2010-12-22 14:59 ` Konrad Rzeszutek Wilk
2010-12-22 20:36 ` [SPAM] " Jeremy Fitzhardinge
2010-12-21 21:37 ` [PATCH 03/10] xen/mmu: Add the notion of IDENTITY_P2M_ENTRY Konrad Rzeszutek Wilk
2010-12-22 8:44 ` Ian Campbell
2010-12-21 21:37 ` [PATCH 04/10] xen/mmu: For 1-1 mapping, automatically set _PAGE_IOMAP Konrad Rzeszutek Wilk
2010-12-21 22:29 ` Jeremy Fitzhardinge
2010-12-22 15:02 ` Konrad Rzeszutek Wilk
2010-12-22 16:27 ` [Xen-devel] " Ian Campbell
2010-12-21 21:37 ` [PATCH 05/10] xen/setup: Set identity mapping for non-RAM E820 and E820 gaps Konrad Rzeszutek Wilk
2010-12-21 22:34 ` Jeremy Fitzhardinge
2010-12-22 15:04 ` Konrad Rzeszutek Wilk
2010-12-22 8:49 ` [Xen-devel] " Ian Campbell
2010-12-21 21:37 ` [PATCH 06/10] xen/setup: Only set identity mapping in E820 regions when privileged Konrad Rzeszutek Wilk
2010-12-21 22:37 ` Jeremy Fitzhardinge
2010-12-22 15:07 ` Konrad Rzeszutek Wilk
2010-12-21 21:37 ` [PATCH 07/10] xen/mmu: Work with 1-1 mappings when allocating new top/middle entries Konrad Rzeszutek Wilk
2010-12-21 22:37 ` Jeremy Fitzhardinge
2010-12-22 15:10 ` Konrad Rzeszutek Wilk
2010-12-22 8:54 ` [Xen-devel] " Ian Campbell
2010-12-22 17:47 ` Konrad Rzeszutek Wilk
2010-12-21 21:37 ` [PATCH 08/10] xen/mmu: Bugfix. Fill the top entry page with appropriate middle layer pointers Konrad Rzeszutek Wilk
2010-12-21 22:38 ` Jeremy Fitzhardinge
2010-12-22 15:11 ` Konrad Rzeszutek Wilk
2010-12-21 21:37 ` [PATCH 09/10] xen/mmu: Be aware of p2m_[mid_|]missing when saving/restore Konrad Rzeszutek Wilk
2010-12-21 21:37 ` [PATCH 10/10] xen/mmu: Warn against races Konrad Rzeszutek Wilk
2010-12-22 8:36 ` [Xen-devel] [RFC PATCH v1] Consider void entries in the P2M as 1-1 mapping Ian Campbell
2010-12-22 15:06 ` Konrad Rzeszutek Wilk
2010-12-22 16:26 ` Ian Campbell
2010-12-22 18:01 ` Konrad Rzeszutek Wilk
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=1292967460-15709-1-git-send-email-konrad.wilk@oracle.com \
--to=konrad.wilk@oracle.com \
--cc=JBeulich@novell.com \
--cc=hpa@zytor.com \
--cc=jeremy@goop.org \
--cc=konrad@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--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 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).