From: "Jan Beulich" <JBeulich@novell.com>
To: xen-devel@lists.xensource.com
Cc: Dave McCracken <dave.mccracken@oracle.com>
Subject: [PATCH] x86: put_superpage() must also work for !opt_allow_superpage
Date: Tue, 15 Jun 2010 13:05:12 +0100 [thread overview]
Message-ID: <4C17889802000078000067B0@vpn.id2.novell.com> (raw)
[-- Attachment #1: Type: text/plain, Size: 2543 bytes --]
This is because the P2M table, when placed at a kernel specified
location, gets populated with large pages, which the domain must have
a way to unmap/recycle.
Additionally when allowing Dom0 to use superpages, they ought to be
tracked accordingly in the superpage frame table.
Signed-off-by: Jan Beulich <jbeulich@novell.com>
--- 2010-06-15.orig/xen/arch/x86/domain_build.c 2010-06-15 12:22:11.000000000 +0200
+++ 2010-06-15/xen/arch/x86/domain_build.c 2010-06-15 11:30:19.000000000 +0200
@@ -913,6 +913,8 @@ int __init construct_dom0(
{
*l2tab = l2e_from_page(page,
L1_PROT|_PAGE_DIRTY|_PAGE_PSE);
+ if ( opt_allow_superpage )
+ get_superpage(page_to_mfn(page), d);
va += 1UL << L2_PAGETABLE_SHIFT;
continue;
}
--- 2010-06-15.orig/xen/arch/x86/mm.c 2010-06-15 12:22:11.000000000 +0200
+++ 2010-06-15/xen/arch/x86/mm.c 2010-06-15 11:31:24.000000000 +0200
@@ -154,7 +154,9 @@ unsigned long __read_mostly pdx_group_va
int opt_allow_superpage;
boolean_param("allowsuperpage", opt_allow_superpage);
+#ifdef __i386__
static int get_superpage(unsigned long mfn, struct domain *d);
+#endif
static void put_superpage(unsigned long mfn);
#define l1_disallow_mask(d) \
@@ -2567,7 +2569,7 @@ void clear_superpage_mark(struct page_in
}
-static int get_superpage(unsigned long mfn, struct domain *d)
+int get_superpage(unsigned long mfn, struct domain *d)
{
struct spage_info *spage;
unsigned long x, nx, y;
@@ -2610,7 +2612,11 @@ static void put_superpage(unsigned long
unsigned long x, nx, y;
unsigned long do_pages = 0;
- ASSERT(opt_allow_superpage);
+ if ( !opt_allow_superpage )
+ {
+ put_spage_pages(mfn_to_page(mfn));
+ return;
+ }
spage = mfn_to_spage(mfn);
y = spage->type_info;
--- 2010-06-15.orig/xen/include/asm-x86/mm.h 2010-06-15 12:22:11.000000000 +0200
+++ 2010-06-15/xen/include/asm-x86/mm.h 2010-06-15 11:28:58.000000000 +0200
@@ -281,6 +281,7 @@ extern void share_xen_page_with_privileg
#define frame_table ((struct page_info *)FRAMETABLE_VIRT_START)
#ifdef __x86_64__
#define spage_table ((struct spage_info *)SPAGETABLE_VIRT_START)
+int get_superpage(unsigned long mfn, struct domain *d);
#endif
extern unsigned long max_page;
extern unsigned long total_pages;
[-- Attachment #2: x86-put-superpage.patch --]
[-- Type: text/plain, Size: 2537 bytes --]
This is because the P2M table, when placed at a kernel specified
location, gets populated with large pages, which the domain must have
a way to unmap/recycle.
Additionally when allowing Dom0 to use superpages, they ought to be
tracked accordingly in the superpage frame table.
Signed-off-by: Jan Beulich <jbeulich@novell.com>
--- 2010-06-15.orig/xen/arch/x86/domain_build.c 2010-06-15 12:22:11.000000000 +0200
+++ 2010-06-15/xen/arch/x86/domain_build.c 2010-06-15 11:30:19.000000000 +0200
@@ -913,6 +913,8 @@ int __init construct_dom0(
{
*l2tab = l2e_from_page(page,
L1_PROT|_PAGE_DIRTY|_PAGE_PSE);
+ if ( opt_allow_superpage )
+ get_superpage(page_to_mfn(page), d);
va += 1UL << L2_PAGETABLE_SHIFT;
continue;
}
--- 2010-06-15.orig/xen/arch/x86/mm.c 2010-06-15 12:22:11.000000000 +0200
+++ 2010-06-15/xen/arch/x86/mm.c 2010-06-15 11:31:24.000000000 +0200
@@ -154,7 +154,9 @@ unsigned long __read_mostly pdx_group_va
int opt_allow_superpage;
boolean_param("allowsuperpage", opt_allow_superpage);
+#ifdef __i386__
static int get_superpage(unsigned long mfn, struct domain *d);
+#endif
static void put_superpage(unsigned long mfn);
#define l1_disallow_mask(d) \
@@ -2567,7 +2569,7 @@ void clear_superpage_mark(struct page_in
}
-static int get_superpage(unsigned long mfn, struct domain *d)
+int get_superpage(unsigned long mfn, struct domain *d)
{
struct spage_info *spage;
unsigned long x, nx, y;
@@ -2610,7 +2612,11 @@ static void put_superpage(unsigned long
unsigned long x, nx, y;
unsigned long do_pages = 0;
- ASSERT(opt_allow_superpage);
+ if ( !opt_allow_superpage )
+ {
+ put_spage_pages(mfn_to_page(mfn));
+ return;
+ }
spage = mfn_to_spage(mfn);
y = spage->type_info;
--- 2010-06-15.orig/xen/include/asm-x86/mm.h 2010-06-15 12:22:11.000000000 +0200
+++ 2010-06-15/xen/include/asm-x86/mm.h 2010-06-15 11:28:58.000000000 +0200
@@ -281,6 +281,7 @@ extern void share_xen_page_with_privileg
#define frame_table ((struct page_info *)FRAMETABLE_VIRT_START)
#ifdef __x86_64__
#define spage_table ((struct spage_info *)SPAGETABLE_VIRT_START)
+int get_superpage(unsigned long mfn, struct domain *d);
#endif
extern unsigned long max_page;
extern unsigned long total_pages;
[-- Attachment #3: Type: text/plain, Size: 138 bytes --]
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
reply other threads:[~2010-06-15 12:05 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
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=4C17889802000078000067B0@vpn.id2.novell.com \
--to=jbeulich@novell.com \
--cc=dave.mccracken@oracle.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 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).