* [RFC][Patches] Xen 1GB Page Table Support
@ 2009-03-18 15:48 Huang2, Wei
2009-03-18 17:20 ` George Dunlap
0 siblings, 1 reply; 23+ messages in thread
From: Huang2, Wei @ 2009-03-18 15:48 UTC (permalink / raw)
To: xen-devel; +Cc: george.dunlap, keir.fraser, Tim Deegan
[-- Attachment #1.1: Type: text/plain, Size: 3437 bytes --]
Current Xen supports 2MB super pages for NPT/EPT. The attached patches
extend this feature to support 1GB pages. The PoD (populate-on-demand)
introduced by George Dunlap made P2M modification harder. I tried to
preserve existing PoD design by introducing a 1GB PoD cache list.
Note that 1GB PoD can be dropped if we don't care about 1GB when PoD is
enabled. In this case, we can just split 1GB PDPE into 512x2MB PDE
entries and grab pages from PoD super list. That can pretty much make
1gb_p2m_pod.patch go away.
Any comment/suggestion on design idea will be appreciated.
Thanks,
-Wei
The following is the description:
=== 1gb_tools.patch ===
Extend existing setup_guest() function. Basically, it tries to allocate
1GB pages whenever available. If this request fails, it falls back to
2MB. If both fail, then 4KB pages will be used.
=== 1gb_p2m.patch ===
* p2m_next_level()
Check PSE bit of L3 page table entry. If 1GB is found (PSE=1), we split
1GB into 512 2MB pages.
* p2m_set_entry()
Configure the PSE bit of L3 P2M table if page order == 18 (1GB).
* p2m_gfn_to_mfn()
Add support for 1GB case when doing gfn to mfn translation. When L3
entry is marked as POPULATE_ON_DEMAND, we call 2m_pod_demand_populate().
Otherwise, we do the regular address translation (gfn ==> mfn).
* p2m_gfn_to_mfn_current()
This is similar to p2m_gfn_to_mfn(). When L3 entry s marked as
POPULATE_ON_DEMAND, it demands a populate using
p2m_pod_demand_populate(). Otherwise, it does a normal translation. 1GB
page is taken into consideration.
* set_p2m_entry()
Request 1GB page
* audit_p2m()
Support 1GB while auditing p2m table.
* p2m_change_type_global()
Deal with 1GB page when changing global page type.
=== 1gb_p2m_pod.patch ===
* xen/include/asm-x86/p2m.h
Minor change to deal with PoD. It separates super page cache list into
2MB and 1GB lists. Similarly, we record last gpfn of sweeping for both
2MB and 1GB.
* p2m_pod_cache_add()
Check page order and add 1GB super page into PoD 1GB cache list.
* p2m_pod_cache_get()
Grab a page from cache list. It tries to break 1GB page into 512 2MB
pages if 2MB PoD list is empty. Similarly, 4KB can be requested from
super pages. The breaking order is 2MB then 1GB.
* p2m_pod_cache_target()
This function is used to set PoD cache size. To increase PoD target, we
try to allocate 1GB from xen domheap. If this fails, we try 2MB. If both
fail, we try 4KB which is guaranteed to work.
To decrease the target, we use a similar approach. We first try to free
1GB pages from 1GB PoD cache list. If such request fails, we try 2MB PoD
cache list. If both fail, we try 4KB list.
* p2m_pod_zero_check_superpage_1gb()
This adds a new function to check for 1GB page. This function is similar
to p2m_pod_zero_check_superpage_2mb().
* p2m_pod_zero_check_superpage_1gb()
We add a new function to sweep 1GB page from guest memory. This is the
same as p2m_pod_zero_check_superpage_2mb().
* p2m_pod_demand_populate()
The trick of this function is to do remap_and_retry if
p2m_pod_cache_get() fails. When p2m_pod_get() fails, this function will
splits p2m table entry into smaller ones (e.g. 1GB ==> 2MB or 2MB ==>
4KB). That can guarantee populate demands always work.
[-- Attachment #1.2: Type: text/html, Size: 7376 bytes --]
[-- Attachment #2: 1gb_tools.patch --]
[-- Type: application/octet-stream, Size: 7472 bytes --]
# HG changeset patch
# User root@weisles1064.amd.com
# Date 1236740196 18000
# Node ID 05aeb649fdab9e8cc3bc541dc3a014658a85611f
# Parent fe4b23bd3a954a640c922202249688eb1b981ce0
1GB nested paging support: tools
diff -r fe4b23bd3a95 -r 05aeb649fdab tools/libxc/xc_hvm_build.c
--- a/tools/libxc/xc_hvm_build.c Wed Mar 18 13:25:25 2009 +0000
+++ b/tools/libxc/xc_hvm_build.c Tue Mar 10 21:56:36 2009 -0500
@@ -19,8 +19,10 @@
#include <xen/libelf/libelf.h>
-#define SUPERPAGE_PFN_SHIFT 9
-#define SUPERPAGE_NR_PFNS (1UL << SUPERPAGE_PFN_SHIFT)
+#define SUPERPAGE_2MB_SHIFT 9
+#define SUPERPAGE_2MB_NR_PFNS (1UL << SUPERPAGE_2MB_SHIFT)
+#define SUPERPAGE_1GB_SHIFT 18
+#define SUPERPAGE_1GB_NR_PFNS (1UL << SUPERPAGE_1GB_SHIFT)
#define SPECIALPAGE_BUFIOREQ 0
#define SPECIALPAGE_XENSTORE 1
@@ -117,6 +119,8 @@ static int setup_guest(int xc_handle,
uint64_t v_start, v_end;
int rc;
xen_capabilities_info_t caps;
+ unsigned long stat_normal_pages = 0, stat_2mb_pages = 0,
+ stat_1gb_pages = 0;
int pod_mode = 0;
@@ -166,35 +170,43 @@ static int setup_guest(int xc_handle,
/*
* Allocate memory for HVM guest, skipping VGA hole 0xA0000-0xC0000.
- * We allocate pages in batches of no more than 8MB to ensure that
- * we can be preempted and hence dom0 remains responsive.
+ *
+ * We attempt to allocate 1GB pages if possible. It falls back on 2MB
+ * pages if 1GB allocation fails. 4KB pages will be used eventually if
+ * both fail.
+ *
+ * Under 2MB mode, we allocate pages in batches of no more than 8MB to
+ * ensure that we can be preempted and hence dom0 remains responsive.
*/
rc = xc_domain_memory_populate_physmap(
xc_handle, dom, 0xa0, 0, 0, &page_array[0x00]);
cur_pages = 0xc0;
+ stat_normal_pages = 0xc0;
while ( (rc == 0) && (nr_pages > cur_pages) )
{
/* Clip count to maximum 8MB extent. */
unsigned long count = nr_pages - cur_pages;
- if ( count > 2048 )
- count = 2048;
-
- /* Clip partial superpage extents to superpage boundaries. */
- if ( ((cur_pages & (SUPERPAGE_NR_PFNS-1)) != 0) &&
- (count > (-cur_pages & (SUPERPAGE_NR_PFNS-1))) )
- count = -cur_pages & (SUPERPAGE_NR_PFNS-1); /* clip s.p. tail */
- else if ( ((count & (SUPERPAGE_NR_PFNS-1)) != 0) &&
- (count > SUPERPAGE_NR_PFNS) )
- count &= ~(SUPERPAGE_NR_PFNS - 1); /* clip non-s.p. tail */
-
- /* Attempt to allocate superpage extents. */
- if ( ((count | cur_pages) & (SUPERPAGE_NR_PFNS - 1)) == 0 )
+ unsigned long max_pages = SUPERPAGE_1GB_NR_PFNS;
+
+ if ( count > max_pages )
+ count = max_pages;
+
+ /* Take care the corner cases of super page tails */
+ if ( ((cur_pages & (SUPERPAGE_1GB_NR_PFNS-1)) != 0) &&
+ (count > (-cur_pages & (SUPERPAGE_1GB_NR_PFNS-1))) )
+ count = -cur_pages & (SUPERPAGE_1GB_NR_PFNS-1);
+ else if ( ((count & (SUPERPAGE_1GB_NR_PFNS-1)) != 0) &&
+ (count > SUPERPAGE_1GB_NR_PFNS) )
+ count &= ~(SUPERPAGE_1GB_NR_PFNS - 1);
+
+ /* Attemp to allocate 1GB super page */
+ if ( ((count | cur_pages) & (SUPERPAGE_1GB_NR_PFNS - 1)) == 0 )
{
long done;
- xen_pfn_t sp_extents[count >> SUPERPAGE_PFN_SHIFT];
+ xen_pfn_t sp_extents[count >> SUPERPAGE_1GB_SHIFT];
struct xen_memory_reservation sp_req = {
- .nr_extents = count >> SUPERPAGE_PFN_SHIFT,
- .extent_order = SUPERPAGE_PFN_SHIFT,
+ .nr_extents = count >> SUPERPAGE_1GB_SHIFT,
+ .extent_order = SUPERPAGE_1GB_SHIFT,
.domid = dom
};
@@ -203,11 +215,12 @@ static int setup_guest(int xc_handle,
set_xen_guest_handle(sp_req.extent_start, sp_extents);
for ( i = 0; i < sp_req.nr_extents; i++ )
- sp_extents[i] = page_array[cur_pages+(i<<SUPERPAGE_PFN_SHIFT)];
+ sp_extents[i] = page_array[cur_pages+(i<<SUPERPAGE_1GB_SHIFT)];
done = xc_memory_op(xc_handle, XENMEM_populate_physmap, &sp_req);
if ( done > 0 )
{
- done <<= SUPERPAGE_PFN_SHIFT;
+ stat_1gb_pages += done;
+ done <<= SUPERPAGE_1GB_SHIFT;
if ( pod_mode && target_pages > cur_pages )
{
int d = target_pages - cur_pages;
@@ -218,12 +231,60 @@ static int setup_guest(int xc_handle,
}
}
+ if ( count != 0 )
+ {
+ max_pages = 2048;
+ if ( count > max_pages )
+ count = max_pages;
+
+ /* Clip partial superpage extents to superpage boundaries. */
+ if ( ((cur_pages & (SUPERPAGE_2MB_NR_PFNS-1)) != 0) &&
+ (count > (-cur_pages & (SUPERPAGE_2MB_NR_PFNS-1))) )
+ count = -cur_pages & (SUPERPAGE_2MB_NR_PFNS-1);
+ else if ( ((count & (SUPERPAGE_2MB_NR_PFNS-1)) != 0) &&
+ (count > SUPERPAGE_2MB_NR_PFNS) )
+ count &= ~(SUPERPAGE_2MB_NR_PFNS - 1); /* clip non-s.p. tail */
+
+ /* Attempt to allocate superpage extents. */
+ if ( ((count | cur_pages) & (SUPERPAGE_2MB_NR_PFNS - 1)) == 0 )
+ {
+ long done;
+ xen_pfn_t sp_extents[count >> SUPERPAGE_2MB_SHIFT];
+ struct xen_memory_reservation sp_req = {
+ .nr_extents = count >> SUPERPAGE_2MB_SHIFT,
+ .extent_order = SUPERPAGE_2MB_SHIFT,
+ .domid = dom
+ };
+
+ if ( pod_mode )
+ sp_req.mem_flags = XENMEMF_populate_on_demand;
+
+ set_xen_guest_handle(sp_req.extent_start, sp_extents);
+ for ( i = 0; i < sp_req.nr_extents; i++ )
+ sp_extents[i] = page_array[cur_pages+(i<<SUPERPAGE_2MB_SHIFT)];
+ done = xc_memory_op(xc_handle, XENMEM_populate_physmap, &sp_req);
+ if ( done > 0 )
+ {
+ stat_2mb_pages += done;
+ done <<= SUPERPAGE_2MB_SHIFT;
+ if ( pod_mode && target_pages > cur_pages )
+ {
+ int d = target_pages - cur_pages;
+ pod_pages += ( done < d ) ? done : d;
+ }
+ cur_pages += done;
+ count -= done;
+ }
+ }
+ }
+
/* Fall back to 4kB extents. */
if ( count != 0 )
{
rc = xc_domain_memory_populate_physmap(
xc_handle, dom, count, 0, 0, &page_array[cur_pages]);
cur_pages += count;
+ stat_normal_pages += count;
if ( pod_mode )
pod_pages -= count;
}
@@ -241,6 +302,12 @@ static int setup_guest(int xc_handle,
goto error_out;
}
+ IPRINTF("PHYSICAL MEMORY ALLOCATION:\n"
+ " 4KB PAGES: 0x%016lx\n"
+ " 2MB PAGES: 0x%016lx\n"
+ " 1GB PAGES: 0x%016lx\n",
+ stat_normal_pages, stat_2mb_pages, stat_1gb_pages);
+
if ( loadelfimage(&elf, xc_handle, dom, page_array) != 0 )
goto error_out;
[-- Attachment #3: 1gb_p2m.patch --]
[-- Type: application/octet-stream, Size: 11420 bytes --]
diff -r 05aeb649fdab -r bacd2a71b6ca xen/arch/x86/mm/p2m.c
--- a/xen/arch/x86/mm/p2m.c Tue Mar 10 21:56:36 2009 -0500
+++ b/xen/arch/x86/mm/p2m.c Tue Mar 10 22:09:22 2009 -0500
@@ -207,7 +207,36 @@ p2m_next_level(struct domain *d, mfn_t *
ASSERT(l1e_get_flags(*p2m_entry) & (_PAGE_PRESENT|_PAGE_PSE));
- /* split single large page into 4KB page in P2M table */
+ /* split 1GB pages into 2MB pages */
+ if ( type == PGT_l2_page_table && (l1e_get_flags(*p2m_entry) & _PAGE_PSE) )
+ {
+ unsigned long flags, pfn;
+ struct page_info *pg = d->arch.p2m->alloc_page(d);
+ if ( pg == NULL )
+ return 0;
+ page_list_add_tail(pg, &d->arch.p2m->pages);
+ pg->u.inuse.type_info = PGT_l1_page_table | 1 | PGT_validated;
+ pg->count_info = 1;
+
+ flags = l1e_get_flags(*p2m_entry);
+ pfn = l1e_get_pfn(*p2m_entry);
+
+ l1_entry = map_domain_page(mfn_x(page_to_mfn(pg)));
+ for ( i = 0; i < L2_PAGETABLE_ENTRIES; i++ )
+ {
+ new_entry = l1e_from_pfn(pfn + (i * L1_PAGETABLE_ENTRIES), flags);
+ paging_write_p2m_entry(d, gfn, l1_entry+i, *table_mfn, new_entry,
+ 2);
+ }
+ unmap_domain_page(l1_entry);
+ new_entry = l1e_from_pfn(mfn_x(page_to_mfn(pg)),
+ __PAGE_HYPERVISOR|_PAGE_USER); //disable PSE
+ paging_write_p2m_entry(d, gfn,
+ p2m_entry, *table_mfn, new_entry, 3);
+ }
+
+
+ /* split single 2MB large page into 4KB page in P2M table */
if ( type == PGT_l1_page_table && (l1e_get_flags(*p2m_entry) & _PAGE_PSE) )
{
unsigned long flags, pfn;
@@ -1116,6 +1145,7 @@ p2m_set_entry(struct domain *d, unsigned
l1_pgentry_t *p2m_entry;
l1_pgentry_t entry_content;
l2_pgentry_t l2e_content;
+ l3_pgentry_t l3e_content;
int rv=0;
#if CONFIG_PAGING_LEVELS >= 4
@@ -1125,18 +1155,44 @@ p2m_set_entry(struct domain *d, unsigned
goto out;
#endif
/*
+ * Try to allocate 1GB page table if this feature is supported.
+ *
* When using PAE Xen, we only allow 33 bits of pseudo-physical
* address in translated guests (i.e. 8 GBytes). This restriction
* comes from wanting to map the P2M table into the 16MB RO_MPT hole
* in Xen's address space for translated PV guests.
* When using AMD's NPT on PAE Xen, we are restricted to 4GB.
*/
- if ( !p2m_next_level(d, &table_mfn, &table, &gfn_remainder, gfn,
- L3_PAGETABLE_SHIFT - PAGE_SHIFT,
- ((CONFIG_PAGING_LEVELS == 3)
- ? (d->arch.hvm_domain.hap_enabled ? 4 : 8)
- : L3_PAGETABLE_ENTRIES),
- PGT_l2_page_table) )
+ if ( page_order == 18 )
+ {
+ p2m_entry = p2m_find_entry(table, &gfn_remainder, gfn,
+ L3_PAGETABLE_SHIFT - PAGE_SHIFT,
+ L3_PAGETABLE_ENTRIES);
+ ASSERT(p2m_entry);
+ if ( (l1e_get_flags(*p2m_entry) & _PAGE_PRESENT) &&
+ !(l1e_get_flags(*p2m_entry) & _PAGE_PSE) )
+ {
+ P2M_ERROR("configure P2M table L3 entry with large page\n");
+ domain_crash(d);
+ goto out;
+ }
+
+ if ( mfn_valid(mfn) )
+ l3e_content = l3e_from_pfn(mfn_x(mfn),
+ __PAGE_HYPERVISOR|_PAGE_USER|_PAGE_PSE);
+ else
+ l3e_content = l3e_empty();
+
+ entry_content.l1 = l3e_content.l3;
+ paging_write_p2m_entry(d, gfn, p2m_entry, table_mfn, entry_content, 3);
+
+ }
+ else if ( !p2m_next_level(d, &table_mfn, &table, &gfn_remainder, gfn,
+ L3_PAGETABLE_SHIFT - PAGE_SHIFT,
+ ((CONFIG_PAGING_LEVELS == 3)
+ ? (d->arch.hvm_domain.hap_enabled ? 4 : 8)
+ : L3_PAGETABLE_ENTRIES),
+ PGT_l2_page_table) )
goto out;
if ( page_order == 0 )
@@ -1158,7 +1214,7 @@ p2m_set_entry(struct domain *d, unsigned
/* level 1 entry */
paging_write_p2m_entry(d, gfn, p2m_entry, table_mfn, entry_content, 1);
}
- else
+ else if ( page_order == 9 )
{
p2m_entry = p2m_find_entry(table, &gfn_remainder, gfn,
L2_PAGETABLE_SHIFT - PAGE_SHIFT,
@@ -1255,11 +1311,32 @@ p2m_gfn_to_mfn(struct domain *d, unsigne
#else
l3e += l3_table_offset(addr);
#endif
+pod_retry_l3:
if ( (l3e_get_flags(*l3e) & _PAGE_PRESENT) == 0 )
{
+ if ( p2m_flags_to_type(l3e_get_flags(*l3e)) == p2m_populate_on_demand )
+ {
+ if ( q != p2m_query )
+ {
+ if ( !p2m_pod_demand_populate(d, gfn, mfn,
+ (l1_pgentry_t *)l3e, 18, q) )
+ goto pod_retry_l3;
+ }
+ else
+ *t = p2m_populate_on_demand;
+ }
unmap_domain_page(l3e);
return _mfn(INVALID_MFN);
}
+ else if ( (l3e_get_flags(*l3e) & _PAGE_PSE) )
+ {
+ mfn = _mfn(l3e_get_pfn(*l3e) +
+ l2_table_offset(addr) * L1_PAGETABLE_ENTRIES +
+ l1_table_offset(addr));
+ unmap_domain_page(l3e);
+ return mfn_valid(mfn) ? mfn : _mfn(INVALID_MFN);
+ }
+
mfn = _mfn(l3e_get_pfn(*l3e));
unmap_domain_page(l3e);
}
@@ -1340,10 +1417,58 @@ static mfn_t p2m_gfn_to_mfn_current(unsi
{
l1_pgentry_t l1e = l1e_empty(), *p2m_entry;
l2_pgentry_t l2e = l2e_empty();
+ l3_pgentry_t l3e = l3e_empty();
int ret;
ASSERT(gfn < (RO_MPT_VIRT_END - RO_MPT_VIRT_START)
/ sizeof(l1_pgentry_t));
+
+ /*
+ * Read & process L3
+ */
+ p2m_entry = (l1_pgentry_t *)
+ &__linear_l2_table[l2_linear_offset(RO_MPT_VIRT_START)
+ + l3_linear_offset(addr)];
+ pod_retry_l3:
+ ret = __copy_from_user(&l3e, p2m_entry, sizeof(l3e));
+
+ if ( ret != 0 || !(l3e_get_flags(l3e) & _PAGE_PRESENT) )
+ {
+ if ( (l3e_get_flags(l3e) & _PAGE_PSE) &&
+ (p2m_flags_to_type(l3e_get_flags(l3e)) == p2m_populate_on_demand) )
+ {
+ /* The read has succeeded, so we know that mapping exists */
+ if ( q != p2m_query )
+ {
+ if ( !p2m_pod_demand_populate(current->domain, gfn, mfn,
+ p2m_entry, 18, q) )
+ goto pod_retry_l3;
+ p2mt = p2m_invalid;
+ printk("%s: Allocate 1GB failed!\n", __func__);
+ goto out;
+ }
+ else
+ {
+ p2mt = p2m_populate_on_demand;
+ goto out;
+ }
+ }
+ goto pod_retry_l2;
+ }
+
+ if ( l3e_get_flags(l3e) & _PAGE_PSE )
+ {
+ p2mt = p2m_flags_to_type(l3e_get_flags(l3e));
+ ASSERT(l3e_get_pfn(l3e) != INVALID_MFN || !p2m_is_ram(p2mt));
+ if (p2m_is_valid(p2mt) )
+ mfn = _mfn(l3e_get_pfn(l3e) +
+ l2_table_offset(addr) * L1_PAGETABLE_ENTRIES +
+ l1_table_offset(addr));
+ else
+ p2mt = p2m_mmio_dm;
+
+ goto out;
+ }
/*
* Read & process L2
@@ -1499,7 +1624,9 @@ int set_p2m_entry(struct domain *d, unsi
while ( todo )
{
- order = (((gfn | mfn_x(mfn) | todo) & ((1ul << 9) - 1)) == 0) ? 9 : 0;
+ order = ( (((gfn | mfn_x(mfn) | todo) & ((1ul << 18) - 1)) == 0) ) ?
+ 18 :
+ (((gfn | mfn_x(mfn) | todo) & ((1ul << 9) - 1)) == 0) ? 9 : 0;
rc = d->arch.p2m->set_entry(d, gfn, mfn, order, p2mt);
gfn += 1ul << order;
if ( mfn_x(mfn) != INVALID_MFN )
@@ -1752,6 +1879,31 @@ static void audit_p2m(struct domain *d)
gfn += 1 << (L3_PAGETABLE_SHIFT - PAGE_SHIFT);
continue;
}
+
+ /* check for 1GB super page */
+ if ( l3e_get_flags(l3e[i3]) & _PAGE_PSE )
+ {
+ mfn = l3e_get_pfn(l3e[i3]);
+ ASSERT(mfn_valid(_mfn(mfn)));
+ /* we have to cover 512x512 4K pages */
+ for ( i2 = 0;
+ i2 < (L2_PAGETABLE_ENTRIES * L1_PAGETABLE_ENTRIES);
+ i2++)
+ {
+ m2pfn = get_gpfn_from_mfn(mfn+i2);
+ if ( m2pfn != (gfn + i2) )
+ {
+ pmbad++;
+ P2M_PRINTK("mismatch: gfn %#lx -> mfn %#lx"
+ " -> gfn %#lx\n", gfn+i2, mfn+i2,
+ m2pfn);
+ BUG();
+ }
+ gfn += 1 << (L3_PAGETABLE_SHIFT - PAGE_SHIFT);
+ continue;
+ }
+ }
+
l2e = map_domain_page(mfn_x(_mfn(l3e_get_pfn(l3e[i3]))));
for ( i2 = 0; i2 < L2_PAGETABLE_ENTRIES; i2++ )
{
@@ -2080,7 +2232,7 @@ void p2m_change_type_global(struct domai
l1_pgentry_t l1e_content;
l1_pgentry_t *l1e;
l2_pgentry_t *l2e;
- mfn_t l1mfn, l2mfn;
+ mfn_t l1mfn, l2mfn, l3mfn;
int i1, i2;
l3_pgentry_t *l3e;
int i3;
@@ -2100,6 +2252,7 @@ void p2m_change_type_global(struct domai
#if CONFIG_PAGING_LEVELS == 4
l4e = map_domain_page(mfn_x(pagetable_get_mfn(d->arch.phys_table)));
#else /* CONFIG_PAGING_LEVELS == 3 */
+ l3mfn = _mfn(mfn_x(pagetable_get_mfn(d->arch.phys_table)));
l3e = map_domain_page(mfn_x(pagetable_get_mfn(d->arch.phys_table)));
#endif
@@ -2110,6 +2263,7 @@ void p2m_change_type_global(struct domai
{
continue;
}
+ l3mfn = _mfn(l4e_get_pfn(l4e[i4]));
l3e = map_domain_page(l4e_get_pfn(l4e[i4]));
#endif
for ( i3 = 0;
@@ -2120,6 +2274,20 @@ void p2m_change_type_global(struct domai
{
continue;
}
+ if ( (l3e_get_flags(l3e[i3]) & _PAGE_PSE) )
+ {
+ flags = l3e_get_flags(l3e[i3]);
+ if ( p2m_flags_to_type(flags) != ot )
+ continue;
+ mfn = l3e_get_pfn(l3e[i3]);
+ gfn = get_gpfn_from_mfn(mfn);
+ flags = p2m_type_to_flags(nt);
+ l1e_content = l1e_from_pfn(mfn, flags | _PAGE_PSE);
+ paging_write_p2m_entry(d, gfn, (l1_pgentry_t *)&l3e[i3],
+ l3mfn, l1e_content, 3);
+ continue;
+ }
+
l2mfn = _mfn(l3e_get_pfn(l3e[i3]));
l2e = map_domain_page(l3e_get_pfn(l3e[i3]));
for ( i2 = 0; i2 < L2_PAGETABLE_ENTRIES; i2++ )
[-- Attachment #4: 1gb_p2m_pod.patch --]
[-- Type: application/octet-stream, Size: 19926 bytes --]
# HG changeset patch
# User root@weisles1064.amd.com
# Date 1236743681 18000
# Node ID f4a674aef64d5ea00ebb05b4bf5a45ab32a4ce25
# Parent bacd2a71b6caadc18031e057edcbf69b45c4b8ec
Xen 1GB nested page table: PoD patches
diff -r bacd2a71b6ca -r f4a674aef64d xen/arch/x86/mm/p2m.c
--- a/xen/arch/x86/mm/p2m.c Tue Mar 10 22:09:22 2009 -0500
+++ b/xen/arch/x86/mm/p2m.c Tue Mar 10 22:54:41 2009 -0500
@@ -335,17 +335,19 @@ p2m_pod_cache_add(struct domain *d,
/* Then add the first one to the appropriate populate-on-demand list */
switch(order)
{
+ case 18:
+ page_list_add_tail(page, &p2md->pod.super1gb);
+ break;
case 9:
- page_list_add_tail(page, &p2md->pod.super); /* lock: page_alloc */
- p2md->pod.count += 1 << order;
+ page_list_add_tail(page, &p2md->pod.super2mb); /* lock: page_alloc */
break;
case 0:
page_list_add_tail(page, &p2md->pod.single); /* lock: page_alloc */
- p2md->pod.count += 1 ;
break;
default:
BUG();
}
+ p2md->pod.count += 1 << order;
spin_unlock(&d->page_alloc_lock);
@@ -353,33 +355,66 @@ p2m_pod_cache_add(struct domain *d,
}
/* Get a page of size order from the populate-on-demand cache. Will break
- * down 2-meg pages into singleton pages automatically. Returns null if
+ * down superpages into singleton pages automatically. Returns null if
* a superpage is requested and no superpages are available. Must be called
* with the d->page_lock held. */
static struct page_info * p2m_pod_cache_get(struct domain *d,
unsigned long order)
{
struct p2m_domain *p2md = d->arch.p2m;
- struct page_info *p = NULL;
+ struct page_info *p = NULL, *q;
+ unsigned long mfn;
int i;
- if ( order == 9 && page_list_empty(&p2md->pod.super) )
+ if ( order == 18 && page_list_empty(&p2md->pod.super1gb) )
{
return NULL;
}
+
+ if ( order == 9 && page_list_empty(&p2md->pod.super2mb) )
+ {
+ /* split 1GB page into 2MB pages */
+ if ( !page_list_empty(&p2md->pod.super1gb) )
+ {
+ printk("%s: breaking up 1GB page into 2MB pages.\n", __func__);
+ p = page_list_remove_head(&p2md->pod.super1gb);
+ mfn = mfn_x(page_to_mfn(p));
+
+ for ( i = 0; i < (1<<9); i++ )
+ {
+ q = mfn_to_page(_mfn(mfn + (i<<9)));
+ page_list_add_tail(q, &p2md->pod.super2mb);
+ }
+ }
+ else
+ return NULL;
+ }
else if ( order == 0 && page_list_empty(&p2md->pod.single) )
{
- unsigned long mfn;
- struct page_info *q;
-
- BUG_ON( page_list_empty(&p2md->pod.super) );
-
+ BUG_ON( page_list_empty(&p2md->pod.super2mb) &&
+ page_list_empty(&p2md->pod.super1gb) );
+
+ if ( !page_list_empty(&p2md->pod.super1gb) &&
+ page_list_empty(&p2md->pod.super2mb) )
+ {
+ printk("%s: breaking up 1GB page into 2MB pages.\n", __func__);
+ p = page_list_remove_head(&p2md->pod.super1gb);
+ mfn = mfn_x(page_to_mfn(p));
+
+ for ( i = 0; i < (1<<9); i++ )
+ {
+ q = mfn_to_page(_mfn(mfn + (i<<9)));
+ page_list_add_tail(q, &p2md->pod.super2mb);
+ }
+ }
+
+
/* Break up a superpage to make single pages. NB count doesn't
* need to be adjusted. */
- printk("%s: Breaking up superpage.\n", __func__);
- p = page_list_remove_head(&p2md->pod.super);
+ printk("%s: breaking up 2MB page into 4KB pages.\n", __func__);
+ p = page_list_remove_head(&p2md->pod.super2mb);
mfn = mfn_x(page_to_mfn(p));
-
+
for ( i=0; i<(1<<9); i++ )
{
q = mfn_to_page(_mfn(mfn+i));
@@ -389,19 +424,22 @@ static struct page_info * p2m_pod_cache_
switch ( order )
{
+ case 18:
+ BUG_ON( page_list_empty(&p2md->pod.super1gb) );
+ p = page_list_remove_head(&p2md->pod.super1gb);
+ break;
case 9:
- BUG_ON( page_list_empty(&p2md->pod.super) );
- p = page_list_remove_head(&p2md->pod.super);
- p2md->pod.count -= 1 << order; /* Lock: page_alloc */
+ BUG_ON( page_list_empty(&p2md->pod.super2mb) );
+ p = page_list_remove_head(&p2md->pod.super2mb);
break;
case 0:
BUG_ON( page_list_empty(&p2md->pod.single) );
p = page_list_remove_head(&p2md->pod.single);
- p2md->pod.count -= 1;
break;
default:
BUG();
}
+ p2md->pod.count -= 1 << order; /* Lock: page_alloc */
/* Put the pages back on the domain page_list */
for ( i = 0 ; i < (1 << order) ; i++ )
@@ -426,14 +464,25 @@ p2m_pod_set_cache_target(struct domain *
struct page_info * page;
int order;
- if ( (pod_target - p2md->pod.count) >= (1>>9) )
+ if ( (pod_target - p2md->pod.count) >= (1>>18) )
+ order = 18;
+ else if ( (pod_target - p2md->pod.count) >= (1>>9) )
order = 9;
else
order = 0;
+increase_try_another_order:
page = alloc_domheap_pages(d, order, 0);
- if ( unlikely(page == NULL) )
- goto out;
+ if ( unlikely(page == NULL) )
+ {
+ if ( order > 0 )
+ {
+ order -= 9;
+ goto increase_try_another_order;
+ }
+ else
+ goto out;
+ }
p2m_pod_cache_add(d, page, order);
}
@@ -446,19 +495,31 @@ p2m_pod_set_cache_target(struct domain *
struct page_info * page;
int order, i;
- /* Grab the lock before checking that pod.super is empty, or the last
- * entries may disappear before we grab the lock. */
+ /* Grab the lock before checking that pod.super2mb is empty, or the
+ * last entries may disappear before we grab the lock. */
spin_lock(&d->page_alloc_lock);
- if ( (p2md->pod.count - pod_target) > (1>>9)
- && !page_list_empty(&p2md->pod.super) )
+
+ if ( (p2md->pod.count - pod_target) > (1>>18) )
+ order = 18;
+ else if ( (p2md->pod.count - pod_target) > (1>>9) )
order = 9;
else
order = 0;
+decrease_try_another_order:
page = p2m_pod_cache_get(d, order);
-
- ASSERT(page != NULL);
+ if ( unlikely(page == NULL) )
+ {
+ if ( order > 0 )
+ {
+ order -= 9;
+ goto decrease_try_another_order;
+ }
+ else
+ goto out;
+ }
+
spin_unlock(&d->page_alloc_lock);
@@ -565,7 +626,20 @@ p2m_pod_empty_cache(struct domain *d)
spin_lock(&d->page_alloc_lock);
- while ( (page = page_list_remove_head(&p2md->pod.super)) )
+ while ( (page = page_list_remove_head(&p2md->pod.super1gb)) )
+ {
+ int i;
+
+ for ( i = 0 ; i < (1 << 18) ; i++ )
+ {
+ BUG_ON(page_get_owner(page + i) != d);
+ page_list_add_tail(page + i, &d->page_list);
+ }
+
+ p2md->pod.count -= 1<<18;
+ }
+
+ while ( (page = page_list_remove_head(&p2md->pod.super2mb)) )
{
int i;
@@ -726,12 +800,12 @@ p2m_pod_dump_data(struct domain *d)
p2md->pod.entry_count, p2md->pod.count);
}
-#define superpage_aligned(_x) (((_x)&((1<<9)-1))==0)
-
-/* Search for all-zero superpages to be reclaimed as superpages for the
+
+/* Search for all-zero 1GB superpages to be reclaimed as superpages for the
* PoD cache. Must be called w/ p2m lock held, page_alloc lock not held. */
+#define superpage_1gb_aligned(_x) (((_x)&((1<<18)-1))==0)
static int
-p2m_pod_zero_check_superpage(struct domain *d, unsigned long gfn)
+p2m_pod_zero_check_superpage_1gb(struct domain *d, unsigned long gfn)
{
mfn_t mfn, mfn0 = _mfn(INVALID_MFN);
p2m_type_t type, type0 = 0;
@@ -740,7 +814,7 @@ p2m_pod_zero_check_superpage(struct doma
int i, j;
int max_ref = 1;
- if ( !superpage_aligned(gfn) )
+ if ( !superpage_1gb_aligned(gfn) )
goto out;
/* Allow an extra refcount for one shadow pt mapping in shadowed domains */
@@ -749,7 +823,7 @@ p2m_pod_zero_check_superpage(struct doma
/* Look up the mfns, checking to make sure they're the same mfn
* and aligned, and mapping them. */
- for ( i=0; i<(1<<9); i++ )
+ for ( i=0; i<(1<<18); i++ )
{
mfn = gfn_to_mfn_query(d, gfn + i, &type);
@@ -776,7 +850,127 @@ p2m_pod_zero_check_superpage(struct doma
|| ( (mfn_to_page(mfn)->count_info & PGC_allocated) == 0 )
|| ( (mfn_to_page(mfn)->count_info & PGC_page_table) != 0 )
|| ( (mfn_to_page(mfn)->count_info & PGC_count_mask) > max_ref )
- || !( ( i == 0 && superpage_aligned(mfn_x(mfn0)) )
+ || !( ( i == 0 && superpage_1gb_aligned(mfn_x(mfn0)) )
+ || ( i != 0 && mfn_x(mfn) == (mfn_x(mfn0) + i) ) ) )
+ goto out;
+ }
+
+ /* Now, do a quick check to see if it may be zero before unmapping. */
+ for ( i=0; i<(1<<18); i++ )
+ {
+ /* Quick zero-check */
+ map = map_domain_page(mfn_x(mfn0) + i);
+
+ for ( j=0; j<16; j++ )
+ if( *(map+j) != 0 )
+ break;
+
+ unmap_domain_page(map);
+
+ if ( j < 16 )
+ goto out;
+
+ }
+
+ /* Try to remove the page, restoring old mapping if it fails. */
+ set_p2m_entry(d, gfn,
+ _mfn(POPULATE_ON_DEMAND_MFN), 18,
+ p2m_populate_on_demand);
+
+ /* Make none of the MFNs are used elsewhere... for example, mapped
+ * via the grant table interface, or by qemu. Allow one refcount for
+ * being allocated to the domain. */
+ for ( i=0; i < (1<<18); i++ )
+ {
+ mfn = _mfn(mfn_x(mfn0) + i);
+ if ( (mfn_to_page(mfn)->count_info & PGC_count_mask) > 1 )
+ {
+ reset = 1;
+ goto out_reset;
+ }
+ }
+
+ /* Finally, do a full zero-check */
+ for ( i=0; i < (1<<18); i++ )
+ {
+ map = map_domain_page(mfn_x(mfn0) + i);
+
+ for ( j=0; j<PAGE_SIZE/sizeof(*map); j++ )
+ if( *(map+j) != 0 )
+ {
+ reset = 1;
+ break;
+ }
+
+ unmap_domain_page(map);
+
+ if ( reset )
+ goto out_reset;
+ }
+
+ /* Finally! We've passed all the checks, and can add the mfn superpage
+ * back on the PoD cache, and account for the new p2m PoD entries */
+ p2m_pod_cache_add(d, mfn_to_page(mfn0), 18);
+ d->arch.p2m->pod.entry_count += (1<<18);
+
+out_reset:
+ if ( reset )
+ set_p2m_entry(d, gfn, mfn0, 18, type0);
+
+out:
+ return ret;
+}
+
+/* Search for all-zero 2MB superpages to be reclaimed as superpages for the
+ * PoD cache. Must be called w/ p2m lock held, page_alloc lock not held. */
+#define superpage_2mb_aligned(_x) (((_x)&((1<<9)-1))==0)
+static int
+p2m_pod_zero_check_superpage_2mb(struct domain *d, unsigned long gfn)
+{
+ mfn_t mfn, mfn0 = _mfn(INVALID_MFN);
+ p2m_type_t type, type0 = 0;
+ unsigned long * map = NULL;
+ int ret=0, reset = 0;
+ int i, j;
+ int max_ref = 1;
+
+ if ( !superpage_2mb_aligned(gfn) )
+ goto out;
+
+ /* Allow an extra refcount for one shadow pt mapping in shadowed domains */
+ if ( paging_mode_shadow(d) )
+ max_ref++;
+
+ /* Look up the mfns, checking to make sure they're the same mfn
+ * and aligned, and mapping them. */
+ for ( i=0; i<(1<<9); i++ )
+ {
+
+ mfn = gfn_to_mfn_query(d, gfn + i, &type);
+
+ if ( i == 0 )
+ {
+ mfn0 = mfn;
+ type0 = type;
+ }
+
+ /* Conditions that must be met for superpage-superpage:
+ * + All gfns are ram types
+ * + All gfns have the same type
+ * + All of the mfns are allocated to a domain
+ * + None of the mfns are used as pagetables
+ * + The first mfn is 2-meg aligned
+ * + All the other mfns are in sequence
+ * Adding for good measure:
+ * + None of the mfns are likely to be mapped elsewhere (refcount
+ * 2 or less for shadow, 1 for hap)
+ */
+ if ( !p2m_is_ram(type)
+ || type != type0
+ || ( (mfn_to_page(mfn)->count_info & PGC_allocated) == 0 )
+ || ( (mfn_to_page(mfn)->count_info & PGC_page_table) != 0 )
+ || ( (mfn_to_page(mfn)->count_info & PGC_count_mask) > max_ref )
+ || !( ( i == 0 && superpage_2mb_aligned(mfn_x(mfn0)) )
|| ( i != 0 && mfn_x(mfn) == (mfn_x(mfn0) + i) ) ) )
goto out;
}
@@ -943,35 +1137,66 @@ p2m_pod_zero_check(struct domain *d, uns
}
+
#define POD_SWEEP_LIMIT 1024
static void
-p2m_pod_emergency_sweep_super(struct domain *d)
+p2m_pod_emergency_sweep_super_1gb(struct domain *d)
{
struct p2m_domain *p2md = d->arch.p2m;
unsigned long i, start, limit;
- if ( p2md->pod.reclaim_super == 0 )
- {
- p2md->pod.reclaim_super = (p2md->pod.max_guest>>9)<<9;
- p2md->pod.reclaim_super -= (1<<9);
+ if ( p2md->pod.reclaim_super_1gb == 0 )
+ {
+ p2md->pod.reclaim_super_1gb = (p2md->pod.max_guest>>18)<<18;
+ p2md->pod.reclaim_super_1gb -= (1<<18);
}
- start = p2md->pod.reclaim_super;
+ start = p2md->pod.reclaim_super_1gb;
limit = (start > POD_SWEEP_LIMIT) ? (start - POD_SWEEP_LIMIT) : 0;
- for ( i=p2md->pod.reclaim_super ; i > 0 ; i-=(1<<9) )
- {
- p2m_pod_zero_check_superpage(d, i);
+ for ( i=p2md->pod.reclaim_super_1gb ; i > 0 ; i-=(1<<18) )
+ {
+ p2m_pod_zero_check_superpage_1gb(d, i);
/* Stop if we're past our limit and we have found *something*.
*
* NB that this is a zero-sum game; we're increasing our cache size
* by increasing our 'debt'. Since we hold the p2m lock,
* (entry_count - count) must remain the same. */
- if ( !page_list_empty(&p2md->pod.super) && i < limit )
+ if ( !page_list_empty(&p2md->pod.super1gb) && i < limit )
break;
}
- p2md->pod.reclaim_super = i ? i - (1<<9) : 0;
+ p2md->pod.reclaim_super_1gb = i ? i - (1<<18) : 0;
+}
+
+static void
+p2m_pod_emergency_sweep_super_2mb(struct domain *d)
+{
+ struct p2m_domain *p2md = d->arch.p2m;
+ unsigned long i, start, limit;
+
+ if ( p2md->pod.reclaim_super_2mb == 0 )
+ {
+ p2md->pod.reclaim_super_2mb = (p2md->pod.max_guest>>9)<<9;
+ p2md->pod.reclaim_super_2mb -= (1<<9);
+ }
+
+ start = p2md->pod.reclaim_super_2mb;
+ limit = (start > POD_SWEEP_LIMIT) ? (start - POD_SWEEP_LIMIT) : 0;
+
+ for ( i=p2md->pod.reclaim_super_2mb ; i > 0 ; i-=(1<<9) )
+ {
+ p2m_pod_zero_check_superpage_2mb(d, i);
+ /* Stop if we're past our limit and we have found *something*.
+ *
+ * NB that this is a zero-sum game; we're increasing our cache size
+ * by increasing our 'debt'. Since we hold the p2m lock,
+ * (entry_count - count) must remain the same. */
+ if ( !page_list_empty(&p2md->pod.super2mb) && i < limit )
+ break;
+ }
+
+ p2md->pod.reclaim_super_2mb = i ? i - (1<<9) : 0;
}
@@ -1049,13 +1274,17 @@ p2m_pod_demand_populate(struct domain *d
return 0;
}
+ /* start a sweep for 1gb page */
+ if ( order == 18 && page_list_empty(&p2md->pod.super1gb) )
+ p2m_pod_emergency_sweep_super_1gb(d);
+
/* If we're low, start a sweep */
- if ( order == 9 && page_list_empty(&p2md->pod.super) )
- p2m_pod_emergency_sweep_super(d);
+ if ( order == 9 && page_list_empty(&p2md->pod.super2mb) )
+ p2m_pod_emergency_sweep_super_2mb(d);
if ( page_list_empty(&p2md->pod.single) &&
( ( order == 0 )
- || (order == 9 && page_list_empty(&p2md->pod.super) ) ) )
+ || (order == 9 && page_list_empty(&p2md->pod.super2mb) ) ) )
p2m_pod_emergency_sweep(d);
/* Keep track of the highest gfn demand-populated by a guest fault */
@@ -1081,6 +1310,15 @@ p2m_pod_demand_populate(struct domain *d
/* Fill in the entry in the p2m */
switch ( order )
{
+ case 18:
+ {
+ l3_pgentry_t l3e_content;
+
+ l3e_content = l3e_from_pfn(mfn_x(mfn),
+ p2m_type_to_flags(p2m_ram_rw) | _PAGE_PSE);
+ entry_content.l1 = l3e_content.l3;
+ }
+ break;
case 9:
{
l2_pgentry_t l2e_content;
@@ -1101,7 +1339,8 @@ p2m_pod_demand_populate(struct domain *d
gfn_aligned = (gfn >> order) << order;
paging_write_p2m_entry(d, gfn_aligned, p2m_entry, table_mfn,
- entry_content, (order==9)?2:1);
+ entry_content,
+ (order==18) ? 3:(order==9) ? 2:1);
for( i = 0 ; i < (1UL << order) ; i++ )
set_gpfn_from_mfn(mfn_x(mfn) + i, gfn_aligned + i);
@@ -1120,14 +1359,24 @@ out_of_memory:
domain_crash(d);
return -1;
remap_and_retry:
- BUG_ON(order != 9);
+ BUG_ON(order != 9 && order != 18);
spin_unlock(&d->page_alloc_lock);
- /* Remap this 2-meg region in singleton chunks */
- gfn_aligned = (gfn>>order)<<order;
- for(i=0; i<(1<<order); i++)
- set_p2m_entry(d, gfn_aligned+i, _mfn(POPULATE_ON_DEMAND_MFN), 0,
- p2m_populate_on_demand);
+ /* Remap this super region in smaller chunks */
+ if ( order == 18 )
+ {
+ gfn_aligned = (gfn>>order)<<order;
+ for(i=0; i<(1<<9); i++)
+ set_p2m_entry(d, gfn_aligned+(i<<9), _mfn(POPULATE_ON_DEMAND_MFN),
+ 9, p2m_populate_on_demand);
+ }
+ else if ( order == 9 )
+ {
+ gfn_aligned = (gfn>>order)<<order;
+ for(i=0; i<(1<<order); i++)
+ set_p2m_entry(d, gfn_aligned+i, _mfn(POPULATE_ON_DEMAND_MFN), 0,
+ p2m_populate_on_demand);
+ }
audit_p2m(d);
p2m_unlock(p2md);
return 0;
@@ -1589,7 +1838,8 @@ int p2m_init(struct domain *d)
memset(p2m, 0, sizeof(*p2m));
p2m_lock_init(p2m);
INIT_PAGE_LIST_HEAD(&p2m->pages);
- INIT_PAGE_LIST_HEAD(&p2m->pod.super);
+ INIT_PAGE_LIST_HEAD(&p2m->pod.super1gb);
+ INIT_PAGE_LIST_HEAD(&p2m->pod.super2mb);
INIT_PAGE_LIST_HEAD(&p2m->pod.single);
p2m->set_entry = p2m_set_entry;
diff -r bacd2a71b6ca -r f4a674aef64d xen/include/asm-x86/p2m.h
--- a/xen/include/asm-x86/p2m.h Tue Mar 10 22:09:22 2009 -0500
+++ b/xen/include/asm-x86/p2m.h Tue Mar 10 22:54:41 2009 -0500
@@ -148,11 +148,13 @@ struct p2m_domain {
* protect moving stuff from the PoD cache to the domain page list.
*/
struct {
- struct page_list_head super, /* List of superpages */
+ struct page_list_head super1gb,/* List of 1GB superpages */
+ super2mb, /* list of 2MB superpages */
single; /* Non-super lists */
int count, /* # of pages in cache lists */
entry_count; /* # of pages in p2m marked pod */
- unsigned reclaim_super; /* Last gpfn of a scan */
+ unsigned reclaim_super_1gb; /* Last gpfn of a 1GB scan */
+ unsigned reclaim_super_2mb; /* last gpfn of a 2MB scan */
unsigned reclaim_single; /* Last gpfn of a scan */
unsigned max_guest; /* gpfn of max guest demand-populate */
} pod;
[-- Attachment #5: Type: text/plain, Size: 138 bytes --]
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
^ permalink raw reply [flat|nested] 23+ messages in thread* Re: [RFC][Patches] Xen 1GB Page Table Support
2009-03-18 15:48 [RFC][Patches] Xen 1GB Page Table Support Huang2, Wei
@ 2009-03-18 17:20 ` George Dunlap
2009-03-18 17:32 ` Keir Fraser
` (2 more replies)
0 siblings, 3 replies; 23+ messages in thread
From: George Dunlap @ 2009-03-18 17:20 UTC (permalink / raw)
To: Huang2, Wei; +Cc: xen-devel, keir.fraser, Tim Deegan
Thanks for doing this work, Wei -- especially all the extra effort for
the PoD integration.
One question: How well would you say you've tested the PoD
functionality? Or to put it the other way, how much do I need to
prioritize testing this before the 3.4 release?
It wouldn't be a bad idea to do as you suggested, and break things
into 2 meg pages for the PoD case. In order to take the best
advantage of this in a PoD scenario, you'd need to have a balloon
driver that could allocate 1G of continuous *guest* p2m space, which
seems a bit optimistic at this point...
-George
2009/3/18 Huang2, Wei <Wei.Huang2@amd.com>:
> Current Xen supports 2MB super pages for NPT/EPT. The attached patches
> extend this feature to support 1GB pages. The PoD (populate-on-demand)
> introduced by George Dunlap made P2M modification harder. I tried to
> preserve existing PoD design by introducing a 1GB PoD cache list.
>
>
>
> Note that 1GB PoD can be dropped if we don't care about 1GB when PoD is
> enabled. In this case, we can just split 1GB PDPE into 512x2MB PDE entries
> and grab pages from PoD super list. That can pretty much make
> 1gb_p2m_pod.patch go away.
>
>
>
> Any comment/suggestion on design idea will be appreciated.
>
>
>
> Thanks,
>
>
>
> -Wei
>
>
>
>
>
> The following is the description:
>
> === 1gb_tools.patch ===
>
> Extend existing setup_guest() function. Basically, it tries to allocate 1GB
> pages whenever available. If this request fails, it falls back to 2MB. If
> both fail, then 4KB pages will be used.
>
>
>
> === 1gb_p2m.patch ===
>
> * p2m_next_level()
>
> Check PSE bit of L3 page table entry. If 1GB is found (PSE=1), we split 1GB
> into 512 2MB pages.
>
>
>
> * p2m_set_entry()
>
> Configure the PSE bit of L3 P2M table if page order == 18 (1GB).
>
>
>
> * p2m_gfn_to_mfn()
>
> Add support for 1GB case when doing gfn to mfn translation. When L3 entry is
> marked as POPULATE_ON_DEMAND, we call 2m_pod_demand_populate(). Otherwise,
> we do the regular address translation (gfn ==> mfn).
>
>
>
> * p2m_gfn_to_mfn_current()
>
> This is similar to p2m_gfn_to_mfn(). When L3 entry s marked as
> POPULATE_ON_DEMAND, it demands a populate using p2m_pod_demand_populate().
> Otherwise, it does a normal translation. 1GB page is taken into
> consideration.
>
>
>
> * set_p2m_entry()
>
> Request 1GB page
>
>
>
> * audit_p2m()
>
> Support 1GB while auditing p2m table.
>
>
>
> * p2m_change_type_global()
>
> Deal with 1GB page when changing global page type.
>
>
>
> === 1gb_p2m_pod.patch ===
>
> * xen/include/asm-x86/p2m.h
>
> Minor change to deal with PoD. It separates super page cache list into 2MB
> and 1GB lists. Similarly, we record last gpfn of sweeping for both 2MB and
> 1GB.
>
>
>
> * p2m_pod_cache_add()
>
> Check page order and add 1GB super page into PoD 1GB cache list.
>
>
>
> * p2m_pod_cache_get()
>
> Grab a page from cache list. It tries to break 1GB page into 512 2MB pages
> if 2MB PoD list is empty. Similarly, 4KB can be requested from super pages.
> The breaking order is 2MB then 1GB.
>
>
>
> * p2m_pod_cache_target()
>
> This function is used to set PoD cache size. To increase PoD target, we try
> to allocate 1GB from xen domheap. If this fails, we try 2MB. If both fail,
> we try 4KB which is guaranteed to work.
>
>
>
> To decrease the target, we use a similar approach. We first try to free 1GB
> pages from 1GB PoD cache list. If such request fails, we try 2MB PoD cache
> list. If both fail, we try 4KB list.
>
>
>
> * p2m_pod_zero_check_superpage_1gb()
>
> This adds a new function to check for 1GB page. This function is similar to
> p2m_pod_zero_check_superpage_2mb().
>
>
>
> * p2m_pod_zero_check_superpage_1gb()
>
> We add a new function to sweep 1GB page from guest memory. This is the same
> as p2m_pod_zero_check_superpage_2mb().
>
>
>
> * p2m_pod_demand_populate()
>
> The trick of this function is to do remap_and_retry if p2m_pod_cache_get()
> fails. When p2m_pod_get() fails, this function will splits p2m table entry
> into smaller ones (e.g. 1GB ==> 2MB or 2MB ==> 4KB). That can guarantee
> populate demands always work.
>
>
>
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel
>
>
^ permalink raw reply [flat|nested] 23+ messages in thread* Re: [RFC][Patches] Xen 1GB Page Table Support
2009-03-18 17:20 ` George Dunlap
@ 2009-03-18 17:32 ` Keir Fraser
2009-03-18 17:45 ` Huang2, Wei
2009-03-18 17:37 ` Huang2, Wei
2009-03-19 8:07 ` Huang2, Wei
2 siblings, 1 reply; 23+ messages in thread
From: Keir Fraser @ 2009-03-18 17:32 UTC (permalink / raw)
To: George Dunlap, Huang2, Wei; +Cc: Tim Deegan, xen-devel@lists.xensource.com
I'm not sure about putting this in for 3.4 unless there's a significant
performance win.
-- Keir
On 18/03/2009 17:20, "George Dunlap" <George.Dunlap@eu.citrix.com> wrote:
> Thanks for doing this work, Wei -- especially all the extra effort for
> the PoD integration.
>
> One question: How well would you say you've tested the PoD
> functionality? Or to put it the other way, how much do I need to
> prioritize testing this before the 3.4 release?
>
> It wouldn't be a bad idea to do as you suggested, and break things
> into 2 meg pages for the PoD case. In order to take the best
> advantage of this in a PoD scenario, you'd need to have a balloon
> driver that could allocate 1G of continuous *guest* p2m space, which
> seems a bit optimistic at this point...
>
> -George
>
> 2009/3/18 Huang2, Wei <Wei.Huang2@amd.com>:
>> Current Xen supports 2MB super pages for NPT/EPT. The attached patches
>> extend this feature to support 1GB pages. The PoD (populate-on-demand)
>> introduced by George Dunlap made P2M modification harder. I tried to
>> preserve existing PoD design by introducing a 1GB PoD cache list.
>>
>>
>>
>> Note that 1GB PoD can be dropped if we don't care about 1GB when PoD is
>> enabled. In this case, we can just split 1GB PDPE into 512x2MB PDE entries
>> and grab pages from PoD super list. That can pretty much make
>> 1gb_p2m_pod.patch go away.
>>
>>
>>
>> Any comment/suggestion on design idea will be appreciated.
>>
>>
>>
>> Thanks,
>>
>>
>>
>> -Wei
>>
>>
>>
>>
>>
>> The following is the description:
>>
>> === 1gb_tools.patch ===
>>
>> Extend existing setup_guest() function. Basically, it tries to allocate 1GB
>> pages whenever available. If this request fails, it falls back to 2MB. If
>> both fail, then 4KB pages will be used.
>>
>>
>>
>> === 1gb_p2m.patch ===
>>
>> * p2m_next_level()
>>
>> Check PSE bit of L3 page table entry. If 1GB is found (PSE=1), we split 1GB
>> into 512 2MB pages.
>>
>>
>>
>> * p2m_set_entry()
>>
>> Configure the PSE bit of L3 P2M table if page order == 18 (1GB).
>>
>>
>>
>> * p2m_gfn_to_mfn()
>>
>> Add support for 1GB case when doing gfn to mfn translation. When L3 entry is
>> marked as POPULATE_ON_DEMAND, we call 2m_pod_demand_populate(). Otherwise,
>> we do the regular address translation (gfn ==> mfn).
>>
>>
>>
>> * p2m_gfn_to_mfn_current()
>>
>> This is similar to p2m_gfn_to_mfn(). When L3 entry s marked as
>> POPULATE_ON_DEMAND, it demands a populate using p2m_pod_demand_populate().
>> Otherwise, it does a normal translation. 1GB page is taken into
>> consideration.
>>
>>
>>
>> * set_p2m_entry()
>>
>> Request 1GB page
>>
>>
>>
>> * audit_p2m()
>>
>> Support 1GB while auditing p2m table.
>>
>>
>>
>> * p2m_change_type_global()
>>
>> Deal with 1GB page when changing global page type.
>>
>>
>>
>> === 1gb_p2m_pod.patch ===
>>
>> * xen/include/asm-x86/p2m.h
>>
>> Minor change to deal with PoD. It separates super page cache list into 2MB
>> and 1GB lists. Similarly, we record last gpfn of sweeping for both 2MB and
>> 1GB.
>>
>>
>>
>> * p2m_pod_cache_add()
>>
>> Check page order and add 1GB super page into PoD 1GB cache list.
>>
>>
>>
>> * p2m_pod_cache_get()
>>
>> Grab a page from cache list. It tries to break 1GB page into 512 2MB pages
>> if 2MB PoD list is empty. Similarly, 4KB can be requested from super pages.
>> The breaking order is 2MB then 1GB.
>>
>>
>>
>> * p2m_pod_cache_target()
>>
>> This function is used to set PoD cache size. To increase PoD target, we try
>> to allocate 1GB from xen domheap. If this fails, we try 2MB. If both fail,
>> we try 4KB which is guaranteed to work.
>>
>>
>>
>> To decrease the target, we use a similar approach. We first try to free 1GB
>> pages from 1GB PoD cache list. If such request fails, we try 2MB PoD cache
>> list. If both fail, we try 4KB list.
>>
>>
>>
>> * p2m_pod_zero_check_superpage_1gb()
>>
>> This adds a new function to check for 1GB page. This function is similar to
>> p2m_pod_zero_check_superpage_2mb().
>>
>>
>>
>> * p2m_pod_zero_check_superpage_1gb()
>>
>> We add a new function to sweep 1GB page from guest memory. This is the same
>> as p2m_pod_zero_check_superpage_2mb().
>>
>>
>>
>> * p2m_pod_demand_populate()
>>
>> The trick of this function is to do remap_and_retry if p2m_pod_cache_get()
>> fails. When p2m_pod_get() fails, this function will splits p2m table entry
>> into smaller ones (e.g. 1GB ==> 2MB or 2MB ==> 4KB). That can guarantee
>> populate demands always work.
>>
>>
>>
>>
>>
>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@lists.xensource.com
>> http://lists.xensource.com/xen-devel
>>
>>
^ permalink raw reply [flat|nested] 23+ messages in thread
* RE: [RFC][Patches] Xen 1GB Page Table Support
2009-03-18 17:32 ` Keir Fraser
@ 2009-03-18 17:45 ` Huang2, Wei
2009-03-18 19:15 ` Keir Fraser
0 siblings, 1 reply; 23+ messages in thread
From: Huang2, Wei @ 2009-03-18 17:45 UTC (permalink / raw)
To: Keir Fraser, George Dunlap; +Cc: Tim Deegan, xen-devel
Keir,
Would you consider the middle approach (tools + normal p2m code) for
3.4? I understand that 1GB PoD is too big. But the middle one is much
simpler.
Thanks,
-Wei
-----Original Message-----
From: Keir Fraser [mailto:keir.fraser@eu.citrix.com]
Sent: Wednesday, March 18, 2009 12:33 PM
To: George Dunlap; Huang2, Wei
Cc: xen-devel@lists.xensource.com; Tim Deegan
Subject: Re: [Xen-devel] [RFC][Patches] Xen 1GB Page Table Support
I'm not sure about putting this in for 3.4 unless there's a significant
performance win.
-- Keir
On 18/03/2009 17:20, "George Dunlap" <George.Dunlap@eu.citrix.com>
wrote:
> Thanks for doing this work, Wei -- especially all the extra effort for
> the PoD integration.
>
> One question: How well would you say you've tested the PoD
> functionality? Or to put it the other way, how much do I need to
> prioritize testing this before the 3.4 release?
>
> It wouldn't be a bad idea to do as you suggested, and break things
> into 2 meg pages for the PoD case. In order to take the best
> advantage of this in a PoD scenario, you'd need to have a balloon
> driver that could allocate 1G of continuous *guest* p2m space, which
> seems a bit optimistic at this point...
>
> -George
>
> 2009/3/18 Huang2, Wei <Wei.Huang2@amd.com>:
>> Current Xen supports 2MB super pages for NPT/EPT. The attached
patches
>> extend this feature to support 1GB pages. The PoD
(populate-on-demand)
>> introduced by George Dunlap made P2M modification harder. I tried to
>> preserve existing PoD design by introducing a 1GB PoD cache list.
>>
>>
>>
>> Note that 1GB PoD can be dropped if we don't care about 1GB when PoD
is
>> enabled. In this case, we can just split 1GB PDPE into 512x2MB PDE
entries
>> and grab pages from PoD super list. That can pretty much make
>> 1gb_p2m_pod.patch go away.
>>
>>
>>
>> Any comment/suggestion on design idea will be appreciated.
>>
>>
>>
>> Thanks,
>>
>>
>>
>> -Wei
>>
>>
>>
>>
>>
>> The following is the description:
>>
>> === 1gb_tools.patch ===
>>
>> Extend existing setup_guest() function. Basically, it tries to
allocate 1GB
>> pages whenever available. If this request fails, it falls back to
2MB. If
>> both fail, then 4KB pages will be used.
>>
>>
>>
>> === 1gb_p2m.patch ===
>>
>> * p2m_next_level()
>>
>> Check PSE bit of L3 page table entry. If 1GB is found (PSE=1), we
split 1GB
>> into 512 2MB pages.
>>
>>
>>
>> * p2m_set_entry()
>>
>> Configure the PSE bit of L3 P2M table if page order == 18 (1GB).
>>
>>
>>
>> * p2m_gfn_to_mfn()
>>
>> Add support for 1GB case when doing gfn to mfn translation. When L3
entry is
>> marked as POPULATE_ON_DEMAND, we call 2m_pod_demand_populate().
Otherwise,
>> we do the regular address translation (gfn ==> mfn).
>>
>>
>>
>> * p2m_gfn_to_mfn_current()
>>
>> This is similar to p2m_gfn_to_mfn(). When L3 entry s marked as
>> POPULATE_ON_DEMAND, it demands a populate using
p2m_pod_demand_populate().
>> Otherwise, it does a normal translation. 1GB page is taken into
>> consideration.
>>
>>
>>
>> * set_p2m_entry()
>>
>> Request 1GB page
>>
>>
>>
>> * audit_p2m()
>>
>> Support 1GB while auditing p2m table.
>>
>>
>>
>> * p2m_change_type_global()
>>
>> Deal with 1GB page when changing global page type.
>>
>>
>>
>> === 1gb_p2m_pod.patch ===
>>
>> * xen/include/asm-x86/p2m.h
>>
>> Minor change to deal with PoD. It separates super page cache list
into 2MB
>> and 1GB lists. Similarly, we record last gpfn of sweeping for both
2MB and
>> 1GB.
>>
>>
>>
>> * p2m_pod_cache_add()
>>
>> Check page order and add 1GB super page into PoD 1GB cache list.
>>
>>
>>
>> * p2m_pod_cache_get()
>>
>> Grab a page from cache list. It tries to break 1GB page into 512 2MB
pages
>> if 2MB PoD list is empty. Similarly, 4KB can be requested from super
pages.
>> The breaking order is 2MB then 1GB.
>>
>>
>>
>> * p2m_pod_cache_target()
>>
>> This function is used to set PoD cache size. To increase PoD target,
we try
>> to allocate 1GB from xen domheap. If this fails, we try 2MB. If both
fail,
>> we try 4KB which is guaranteed to work.
>>
>>
>>
>> To decrease the target, we use a similar approach. We first try to
free 1GB
>> pages from 1GB PoD cache list. If such request fails, we try 2MB PoD
cache
>> list. If both fail, we try 4KB list.
>>
>>
>>
>> * p2m_pod_zero_check_superpage_1gb()
>>
>> This adds a new function to check for 1GB page. This function is
similar to
>> p2m_pod_zero_check_superpage_2mb().
>>
>>
>>
>> * p2m_pod_zero_check_superpage_1gb()
>>
>> We add a new function to sweep 1GB page from guest memory. This is
the same
>> as p2m_pod_zero_check_superpage_2mb().
>>
>>
>>
>> * p2m_pod_demand_populate()
>>
>> The trick of this function is to do remap_and_retry if
p2m_pod_cache_get()
>> fails. When p2m_pod_get() fails, this function will splits p2m table
entry
>> into smaller ones (e.g. 1GB ==> 2MB or 2MB ==> 4KB). That can
guarantee
>> populate demands always work.
>>
>>
>>
>>
>>
>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@lists.xensource.com
>> http://lists.xensource.com/xen-devel
>>
>>
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [RFC][Patches] Xen 1GB Page Table Support
2009-03-18 17:45 ` Huang2, Wei
@ 2009-03-18 19:15 ` Keir Fraser
0 siblings, 0 replies; 23+ messages in thread
From: Keir Fraser @ 2009-03-18 19:15 UTC (permalink / raw)
To: Huang2, Wei, George Dunlap; +Cc: Tim Deegan, xen-devel@lists.xensource.com
Yes, I might.
-- Keir
On 18/03/2009 17:45, "Huang2, Wei" <Wei.Huang2@amd.com> wrote:
> Keir,
>
> Would you consider the middle approach (tools + normal p2m code) for
> 3.4? I understand that 1GB PoD is too big. But the middle one is much
> simpler.
>
> Thanks,
>
> -Wei
>
> -----Original Message-----
> From: Keir Fraser [mailto:keir.fraser@eu.citrix.com]
> Sent: Wednesday, March 18, 2009 12:33 PM
> To: George Dunlap; Huang2, Wei
> Cc: xen-devel@lists.xensource.com; Tim Deegan
> Subject: Re: [Xen-devel] [RFC][Patches] Xen 1GB Page Table Support
>
> I'm not sure about putting this in for 3.4 unless there's a significant
> performance win.
>
> -- Keir
>
> On 18/03/2009 17:20, "George Dunlap" <George.Dunlap@eu.citrix.com>
> wrote:
>
>> Thanks for doing this work, Wei -- especially all the extra effort for
>> the PoD integration.
>>
>> One question: How well would you say you've tested the PoD
>> functionality? Or to put it the other way, how much do I need to
>> prioritize testing this before the 3.4 release?
>>
>> It wouldn't be a bad idea to do as you suggested, and break things
>> into 2 meg pages for the PoD case. In order to take the best
>> advantage of this in a PoD scenario, you'd need to have a balloon
>> driver that could allocate 1G of continuous *guest* p2m space, which
>> seems a bit optimistic at this point...
>>
>> -George
>>
>> 2009/3/18 Huang2, Wei <Wei.Huang2@amd.com>:
>>> Current Xen supports 2MB super pages for NPT/EPT. The attached
> patches
>>> extend this feature to support 1GB pages. The PoD
> (populate-on-demand)
>>> introduced by George Dunlap made P2M modification harder. I tried to
>>> preserve existing PoD design by introducing a 1GB PoD cache list.
>>>
>>>
>>>
>>> Note that 1GB PoD can be dropped if we don't care about 1GB when PoD
> is
>>> enabled. In this case, we can just split 1GB PDPE into 512x2MB PDE
> entries
>>> and grab pages from PoD super list. That can pretty much make
>>> 1gb_p2m_pod.patch go away.
>>>
>>>
>>>
>>> Any comment/suggestion on design idea will be appreciated.
>>>
>>>
>>>
>>> Thanks,
>>>
>>>
>>>
>>> -Wei
>>>
>>>
>>>
>>>
>>>
>>> The following is the description:
>>>
>>> === 1gb_tools.patch ===
>>>
>>> Extend existing setup_guest() function. Basically, it tries to
> allocate 1GB
>>> pages whenever available. If this request fails, it falls back to
> 2MB. If
>>> both fail, then 4KB pages will be used.
>>>
>>>
>>>
>>> === 1gb_p2m.patch ===
>>>
>>> * p2m_next_level()
>>>
>>> Check PSE bit of L3 page table entry. If 1GB is found (PSE=1), we
> split 1GB
>>> into 512 2MB pages.
>>>
>>>
>>>
>>> * p2m_set_entry()
>>>
>>> Configure the PSE bit of L3 P2M table if page order == 18 (1GB).
>>>
>>>
>>>
>>> * p2m_gfn_to_mfn()
>>>
>>> Add support for 1GB case when doing gfn to mfn translation. When L3
> entry is
>>> marked as POPULATE_ON_DEMAND, we call 2m_pod_demand_populate().
> Otherwise,
>>> we do the regular address translation (gfn ==> mfn).
>>>
>>>
>>>
>>> * p2m_gfn_to_mfn_current()
>>>
>>> This is similar to p2m_gfn_to_mfn(). When L3 entry s marked as
>>> POPULATE_ON_DEMAND, it demands a populate using
> p2m_pod_demand_populate().
>>> Otherwise, it does a normal translation. 1GB page is taken into
>>> consideration.
>>>
>>>
>>>
>>> * set_p2m_entry()
>>>
>>> Request 1GB page
>>>
>>>
>>>
>>> * audit_p2m()
>>>
>>> Support 1GB while auditing p2m table.
>>>
>>>
>>>
>>> * p2m_change_type_global()
>>>
>>> Deal with 1GB page when changing global page type.
>>>
>>>
>>>
>>> === 1gb_p2m_pod.patch ===
>>>
>>> * xen/include/asm-x86/p2m.h
>>>
>>> Minor change to deal with PoD. It separates super page cache list
> into 2MB
>>> and 1GB lists. Similarly, we record last gpfn of sweeping for both
> 2MB and
>>> 1GB.
>>>
>>>
>>>
>>> * p2m_pod_cache_add()
>>>
>>> Check page order and add 1GB super page into PoD 1GB cache list.
>>>
>>>
>>>
>>> * p2m_pod_cache_get()
>>>
>>> Grab a page from cache list. It tries to break 1GB page into 512 2MB
> pages
>>> if 2MB PoD list is empty. Similarly, 4KB can be requested from super
> pages.
>>> The breaking order is 2MB then 1GB.
>>>
>>>
>>>
>>> * p2m_pod_cache_target()
>>>
>>> This function is used to set PoD cache size. To increase PoD target,
> we try
>>> to allocate 1GB from xen domheap. If this fails, we try 2MB. If both
> fail,
>>> we try 4KB which is guaranteed to work.
>>>
>>>
>>>
>>> To decrease the target, we use a similar approach. We first try to
> free 1GB
>>> pages from 1GB PoD cache list. If such request fails, we try 2MB PoD
> cache
>>> list. If both fail, we try 4KB list.
>>>
>>>
>>>
>>> * p2m_pod_zero_check_superpage_1gb()
>>>
>>> This adds a new function to check for 1GB page. This function is
> similar to
>>> p2m_pod_zero_check_superpage_2mb().
>>>
>>>
>>>
>>> * p2m_pod_zero_check_superpage_1gb()
>>>
>>> We add a new function to sweep 1GB page from guest memory. This is
> the same
>>> as p2m_pod_zero_check_superpage_2mb().
>>>
>>>
>>>
>>> * p2m_pod_demand_populate()
>>>
>>> The trick of this function is to do remap_and_retry if
> p2m_pod_cache_get()
>>> fails. When p2m_pod_get() fails, this function will splits p2m table
> entry
>>> into smaller ones (e.g. 1GB ==> 2MB or 2MB ==> 4KB). That can
> guarantee
>>> populate demands always work.
>>>
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> Xen-devel mailing list
>>> Xen-devel@lists.xensource.com
>>> http://lists.xensource.com/xen-devel
>>>
>>>
>
>
>
>
^ permalink raw reply [flat|nested] 23+ messages in thread
* RE: [RFC][Patches] Xen 1GB Page Table Support
2009-03-18 17:20 ` George Dunlap
2009-03-18 17:32 ` Keir Fraser
@ 2009-03-18 17:37 ` Huang2, Wei
2009-03-19 8:07 ` Huang2, Wei
2 siblings, 0 replies; 23+ messages in thread
From: Huang2, Wei @ 2009-03-18 17:37 UTC (permalink / raw)
To: George Dunlap; +Cc: xen-devel, keir.fraser, Tim Deegan
George,
Thanks for your comments. I tested the first two parts (tools and
1gb_p2m). They are relatively straightforward in my opinion. As for the
third one (PoD), I just started the testing. So it still needs quit a
lot of testing efforts.
If you feel the intermediate approach (tools + 1gb_p2m) is more
appealing, I will submit another patch today.
-Wei
-----Original Message-----
From: dunlapg@gmail.com [mailto:dunlapg@gmail.com] On Behalf Of George
Dunlap
Sent: Wednesday, March 18, 2009 12:20 PM
To: Huang2, Wei
Cc: xen-devel@lists.xensource.com; keir.fraser@eu.citrix.com; Tim Deegan
Subject: Re: [Xen-devel] [RFC][Patches] Xen 1GB Page Table Support
Thanks for doing this work, Wei -- especially all the extra effort for
the PoD integration.
One question: How well would you say you've tested the PoD
functionality? Or to put it the other way, how much do I need to
prioritize testing this before the 3.4 release?
It wouldn't be a bad idea to do as you suggested, and break things
into 2 meg pages for the PoD case. In order to take the best
advantage of this in a PoD scenario, you'd need to have a balloon
driver that could allocate 1G of continuous *guest* p2m space, which
seems a bit optimistic at this point...
-George
2009/3/18 Huang2, Wei <Wei.Huang2@amd.com>:
> Current Xen supports 2MB super pages for NPT/EPT. The attached patches
> extend this feature to support 1GB pages. The PoD (populate-on-demand)
> introduced by George Dunlap made P2M modification harder. I tried to
> preserve existing PoD design by introducing a 1GB PoD cache list.
>
>
>
> Note that 1GB PoD can be dropped if we don't care about 1GB when PoD
is
> enabled. In this case, we can just split 1GB PDPE into 512x2MB PDE
entries
> and grab pages from PoD super list. That can pretty much make
> 1gb_p2m_pod.patch go away.
>
>
>
> Any comment/suggestion on design idea will be appreciated.
>
>
>
> Thanks,
>
>
>
> -Wei
>
>
>
>
>
> The following is the description:
>
> === 1gb_tools.patch ===
>
> Extend existing setup_guest() function. Basically, it tries to
allocate 1GB
> pages whenever available. If this request fails, it falls back to 2MB.
If
> both fail, then 4KB pages will be used.
>
>
>
> === 1gb_p2m.patch ===
>
> * p2m_next_level()
>
> Check PSE bit of L3 page table entry. If 1GB is found (PSE=1), we
split 1GB
> into 512 2MB pages.
>
>
>
> * p2m_set_entry()
>
> Configure the PSE bit of L3 P2M table if page order == 18 (1GB).
>
>
>
> * p2m_gfn_to_mfn()
>
> Add support for 1GB case when doing gfn to mfn translation. When L3
entry is
> marked as POPULATE_ON_DEMAND, we call 2m_pod_demand_populate().
Otherwise,
> we do the regular address translation (gfn ==> mfn).
>
>
>
> * p2m_gfn_to_mfn_current()
>
> This is similar to p2m_gfn_to_mfn(). When L3 entry s marked as
> POPULATE_ON_DEMAND, it demands a populate using
p2m_pod_demand_populate().
> Otherwise, it does a normal translation. 1GB page is taken into
> consideration.
>
>
>
> * set_p2m_entry()
>
> Request 1GB page
>
>
>
> * audit_p2m()
>
> Support 1GB while auditing p2m table.
>
>
>
> * p2m_change_type_global()
>
> Deal with 1GB page when changing global page type.
>
>
>
> === 1gb_p2m_pod.patch ===
>
> * xen/include/asm-x86/p2m.h
>
> Minor change to deal with PoD. It separates super page cache list into
2MB
> and 1GB lists. Similarly, we record last gpfn of sweeping for both 2MB
and
> 1GB.
>
>
>
> * p2m_pod_cache_add()
>
> Check page order and add 1GB super page into PoD 1GB cache list.
>
>
>
> * p2m_pod_cache_get()
>
> Grab a page from cache list. It tries to break 1GB page into 512 2MB
pages
> if 2MB PoD list is empty. Similarly, 4KB can be requested from super
pages.
> The breaking order is 2MB then 1GB.
>
>
>
> * p2m_pod_cache_target()
>
> This function is used to set PoD cache size. To increase PoD target,
we try
> to allocate 1GB from xen domheap. If this fails, we try 2MB. If both
fail,
> we try 4KB which is guaranteed to work.
>
>
>
> To decrease the target, we use a similar approach. We first try to
free 1GB
> pages from 1GB PoD cache list. If such request fails, we try 2MB PoD
cache
> list. If both fail, we try 4KB list.
>
>
>
> * p2m_pod_zero_check_superpage_1gb()
>
> This adds a new function to check for 1GB page. This function is
similar to
> p2m_pod_zero_check_superpage_2mb().
>
>
>
> * p2m_pod_zero_check_superpage_1gb()
>
> We add a new function to sweep 1GB page from guest memory. This is the
same
> as p2m_pod_zero_check_superpage_2mb().
>
>
>
> * p2m_pod_demand_populate()
>
> The trick of this function is to do remap_and_retry if
p2m_pod_cache_get()
> fails. When p2m_pod_get() fails, this function will splits p2m table
entry
> into smaller ones (e.g. 1GB ==> 2MB or 2MB ==> 4KB). That can
guarantee
> populate demands always work.
>
>
>
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel
>
>
^ permalink raw reply [flat|nested] 23+ messages in thread
* RE: [RFC][Patches] Xen 1GB Page Table Support
2009-03-18 17:20 ` George Dunlap
2009-03-18 17:32 ` Keir Fraser
2009-03-18 17:37 ` Huang2, Wei
@ 2009-03-19 8:07 ` Huang2, Wei
2009-03-19 14:17 ` Dan Magenheimer
` (2 more replies)
2 siblings, 3 replies; 23+ messages in thread
From: Huang2, Wei @ 2009-03-19 8:07 UTC (permalink / raw)
To: George Dunlap; +Cc: xen-devel, keir.fraser, Tim Deegan
[-- Attachment #1: Type: text/plain, Size: 4957 bytes --]
Here are patches using the middle approach. It handles 1GB pages in PoD
by remapping 1GB with 2MB pages & retry. I also added code for 1GB
detection. Please comment.
Thanks a lot,
-Wei
-----Original Message-----
From: dunlapg@gmail.com [mailto:dunlapg@gmail.com] On Behalf Of George
Dunlap
Sent: Wednesday, March 18, 2009 12:20 PM
To: Huang2, Wei
Cc: xen-devel@lists.xensource.com; keir.fraser@eu.citrix.com; Tim Deegan
Subject: Re: [Xen-devel] [RFC][Patches] Xen 1GB Page Table Support
Thanks for doing this work, Wei -- especially all the extra effort for
the PoD integration.
One question: How well would you say you've tested the PoD
functionality? Or to put it the other way, how much do I need to
prioritize testing this before the 3.4 release?
It wouldn't be a bad idea to do as you suggested, and break things
into 2 meg pages for the PoD case. In order to take the best
advantage of this in a PoD scenario, you'd need to have a balloon
driver that could allocate 1G of continuous *guest* p2m space, which
seems a bit optimistic at this point...
-George
2009/3/18 Huang2, Wei <Wei.Huang2@amd.com>:
> Current Xen supports 2MB super pages for NPT/EPT. The attached patches
> extend this feature to support 1GB pages. The PoD (populate-on-demand)
> introduced by George Dunlap made P2M modification harder. I tried to
> preserve existing PoD design by introducing a 1GB PoD cache list.
>
>
>
> Note that 1GB PoD can be dropped if we don't care about 1GB when PoD
is
> enabled. In this case, we can just split 1GB PDPE into 512x2MB PDE
entries
> and grab pages from PoD super list. That can pretty much make
> 1gb_p2m_pod.patch go away.
>
>
>
> Any comment/suggestion on design idea will be appreciated.
>
>
>
> Thanks,
>
>
>
> -Wei
>
>
>
>
>
> The following is the description:
>
> === 1gb_tools.patch ===
>
> Extend existing setup_guest() function. Basically, it tries to
allocate 1GB
> pages whenever available. If this request fails, it falls back to 2MB.
If
> both fail, then 4KB pages will be used.
>
>
>
> === 1gb_p2m.patch ===
>
> * p2m_next_level()
>
> Check PSE bit of L3 page table entry. If 1GB is found (PSE=1), we
split 1GB
> into 512 2MB pages.
>
>
>
> * p2m_set_entry()
>
> Configure the PSE bit of L3 P2M table if page order == 18 (1GB).
>
>
>
> * p2m_gfn_to_mfn()
>
> Add support for 1GB case when doing gfn to mfn translation. When L3
entry is
> marked as POPULATE_ON_DEMAND, we call 2m_pod_demand_populate().
Otherwise,
> we do the regular address translation (gfn ==> mfn).
>
>
>
> * p2m_gfn_to_mfn_current()
>
> This is similar to p2m_gfn_to_mfn(). When L3 entry s marked as
> POPULATE_ON_DEMAND, it demands a populate using
p2m_pod_demand_populate().
> Otherwise, it does a normal translation. 1GB page is taken into
> consideration.
>
>
>
> * set_p2m_entry()
>
> Request 1GB page
>
>
>
> * audit_p2m()
>
> Support 1GB while auditing p2m table.
>
>
>
> * p2m_change_type_global()
>
> Deal with 1GB page when changing global page type.
>
>
>
> === 1gb_p2m_pod.patch ===
>
> * xen/include/asm-x86/p2m.h
>
> Minor change to deal with PoD. It separates super page cache list into
2MB
> and 1GB lists. Similarly, we record last gpfn of sweeping for both 2MB
and
> 1GB.
>
>
>
> * p2m_pod_cache_add()
>
> Check page order and add 1GB super page into PoD 1GB cache list.
>
>
>
> * p2m_pod_cache_get()
>
> Grab a page from cache list. It tries to break 1GB page into 512 2MB
pages
> if 2MB PoD list is empty. Similarly, 4KB can be requested from super
pages.
> The breaking order is 2MB then 1GB.
>
>
>
> * p2m_pod_cache_target()
>
> This function is used to set PoD cache size. To increase PoD target,
we try
> to allocate 1GB from xen domheap. If this fails, we try 2MB. If both
fail,
> we try 4KB which is guaranteed to work.
>
>
>
> To decrease the target, we use a similar approach. We first try to
free 1GB
> pages from 1GB PoD cache list. If such request fails, we try 2MB PoD
cache
> list. If both fail, we try 4KB list.
>
>
>
> * p2m_pod_zero_check_superpage_1gb()
>
> This adds a new function to check for 1GB page. This function is
similar to
> p2m_pod_zero_check_superpage_2mb().
>
>
>
> * p2m_pod_zero_check_superpage_1gb()
>
> We add a new function to sweep 1GB page from guest memory. This is the
same
> as p2m_pod_zero_check_superpage_2mb().
>
>
>
> * p2m_pod_demand_populate()
>
> The trick of this function is to do remap_and_retry if
p2m_pod_cache_get()
> fails. When p2m_pod_get() fails, this function will splits p2m table
entry
> into smaller ones (e.g. 1GB ==> 2MB or 2MB ==> 4KB). That can
guarantee
> populate demands always work.
>
>
>
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel
>
>
[-- Attachment #2: 1gb_tools.patch --]
[-- Type: application/octet-stream, Size: 7365 bytes --]
diff -r e821a12d92a9 -r 993b10a7eaa4 tools/libxc/xc_hvm_build.c
--- a/tools/libxc/xc_hvm_build.c Wed Mar 11 06:25:58 2009 -0500
+++ b/tools/libxc/xc_hvm_build.c Wed Mar 11 13:48:21 2009 -0500
@@ -19,8 +19,10 @@
#include <xen/libelf/libelf.h>
-#define SUPERPAGE_PFN_SHIFT 9
-#define SUPERPAGE_NR_PFNS (1UL << SUPERPAGE_PFN_SHIFT)
+#define SUPERPAGE_2MB_SHIFT 9
+#define SUPERPAGE_2MB_NR_PFNS (1UL << SUPERPAGE_2MB_SHIFT)
+#define SUPERPAGE_1GB_SHIFT 18
+#define SUPERPAGE_1GB_NR_PFNS (1UL << SUPERPAGE_1GB_SHIFT)
#define SPECIALPAGE_BUFIOREQ 0
#define SPECIALPAGE_XENSTORE 1
@@ -117,6 +119,8 @@ static int setup_guest(int xc_handle,
uint64_t v_start, v_end;
int rc;
xen_capabilities_info_t caps;
+ unsigned long stats_normal_pages = 0, stats_2mb_pages = 0,
+ stats_1gb_pages = 0;
int pod_mode = 0;
@@ -166,35 +170,42 @@ static int setup_guest(int xc_handle,
/*
* Allocate memory for HVM guest, skipping VGA hole 0xA0000-0xC0000.
- * We allocate pages in batches of no more than 8MB to ensure that
- * we can be preempted and hence dom0 remains responsive.
+ *
+ * We attempt to allocate 1GB pages if possible. It falls back on 2MB
+ * pages if 1GB allocation fails. 4KB pages will be used eventually if
+ * both fail.
+ *
+ * Under 2MB mode, we allocate pages in batches of no more than 8MB to
+ * ensure that we can be preempted and hence dom0 remains responsive.
*/
rc = xc_domain_memory_populate_physmap(
xc_handle, dom, 0xa0, 0, 0, &page_array[0x00]);
cur_pages = 0xc0;
+ stats_normal_pages = 0xc0;
while ( (rc == 0) && (nr_pages > cur_pages) )
{
- /* Clip count to maximum 8MB extent. */
unsigned long count = nr_pages - cur_pages;
- if ( count > 2048 )
- count = 2048;
-
- /* Clip partial superpage extents to superpage boundaries. */
- if ( ((cur_pages & (SUPERPAGE_NR_PFNS-1)) != 0) &&
- (count > (-cur_pages & (SUPERPAGE_NR_PFNS-1))) )
- count = -cur_pages & (SUPERPAGE_NR_PFNS-1); /* clip s.p. tail */
- else if ( ((count & (SUPERPAGE_NR_PFNS-1)) != 0) &&
- (count > SUPERPAGE_NR_PFNS) )
- count &= ~(SUPERPAGE_NR_PFNS - 1); /* clip non-s.p. tail */
-
- /* Attempt to allocate superpage extents. */
- if ( ((count | cur_pages) & (SUPERPAGE_NR_PFNS - 1)) == 0 )
+ unsigned long max_pages = SUPERPAGE_1GB_NR_PFNS;
+
+ if ( count > max_pages )
+ count = max_pages;
+
+ /* Take care the corner cases of super page tails */
+ if ( ((cur_pages & (SUPERPAGE_1GB_NR_PFNS-1)) != 0) &&
+ (count > (-cur_pages & (SUPERPAGE_1GB_NR_PFNS-1))) )
+ count = -cur_pages & (SUPERPAGE_1GB_NR_PFNS-1);
+ else if ( ((count & (SUPERPAGE_1GB_NR_PFNS-1)) != 0) &&
+ (count > SUPERPAGE_1GB_NR_PFNS) )
+ count &= ~(SUPERPAGE_1GB_NR_PFNS - 1);
+
+ /* Attemp to allocate 1GB super page */
+ if ( ((count | cur_pages) & (SUPERPAGE_1GB_NR_PFNS - 1)) == 0 )
{
long done;
- xen_pfn_t sp_extents[count >> SUPERPAGE_PFN_SHIFT];
+ xen_pfn_t sp_extents[count >> SUPERPAGE_1GB_SHIFT];
struct xen_memory_reservation sp_req = {
- .nr_extents = count >> SUPERPAGE_PFN_SHIFT,
- .extent_order = SUPERPAGE_PFN_SHIFT,
+ .nr_extents = count >> SUPERPAGE_1GB_SHIFT,
+ .extent_order = SUPERPAGE_1GB_SHIFT,
.domid = dom
};
@@ -203,11 +214,12 @@ static int setup_guest(int xc_handle,
set_xen_guest_handle(sp_req.extent_start, sp_extents);
for ( i = 0; i < sp_req.nr_extents; i++ )
- sp_extents[i] = page_array[cur_pages+(i<<SUPERPAGE_PFN_SHIFT)];
+ sp_extents[i] = page_array[cur_pages+(i<<SUPERPAGE_1GB_SHIFT)];
done = xc_memory_op(xc_handle, XENMEM_populate_physmap, &sp_req);
if ( done > 0 )
{
- done <<= SUPERPAGE_PFN_SHIFT;
+ stats_1gb_pages += done;
+ done <<= SUPERPAGE_1GB_SHIFT;
if ( pod_mode && target_pages > cur_pages )
{
int d = target_pages - cur_pages;
@@ -218,12 +230,62 @@ static int setup_guest(int xc_handle,
}
}
+ /* Fall back to 2MB allocation */
+ if ( count != 0 )
+ {
+ /* Clip count to maximum 8MB extent. */
+ max_pages = 2048;
+ if ( count > max_pages )
+ count = max_pages;
+
+ /* Clip partial superpage extents to superpage boundaries. */
+ if ( ((cur_pages & (SUPERPAGE_2MB_NR_PFNS-1)) != 0) &&
+ (count > (-cur_pages & (SUPERPAGE_2MB_NR_PFNS-1))) )
+ count = -cur_pages & (SUPERPAGE_2MB_NR_PFNS-1);
+ else if ( ((count & (SUPERPAGE_2MB_NR_PFNS-1)) != 0) &&
+ (count > SUPERPAGE_2MB_NR_PFNS) )
+ count &= ~(SUPERPAGE_2MB_NR_PFNS - 1); /* clip non-s.p. tail */
+
+ /* Attempt to allocate superpage extents. */
+ if ( ((count | cur_pages) & (SUPERPAGE_2MB_NR_PFNS - 1)) == 0 )
+ {
+ long done;
+ xen_pfn_t sp_extents[count >> SUPERPAGE_2MB_SHIFT];
+ struct xen_memory_reservation sp_req = {
+ .nr_extents = count >> SUPERPAGE_2MB_SHIFT,
+ .extent_order = SUPERPAGE_2MB_SHIFT,
+ .domid = dom
+ };
+
+ if ( pod_mode )
+ sp_req.mem_flags = XENMEMF_populate_on_demand;
+
+ set_xen_guest_handle(sp_req.extent_start, sp_extents);
+ for ( i = 0; i < sp_req.nr_extents; i++ )
+ sp_extents[i] = page_array[cur_pages+(i<<SUPERPAGE_2MB_SHIFT)];
+ done = xc_memory_op(xc_handle, XENMEM_populate_physmap, &sp_req);
+ if ( done > 0 )
+ {
+ stats_2mb_pages += done;
+ done <<= SUPERPAGE_2MB_SHIFT;
+ if ( pod_mode && target_pages > cur_pages )
+ {
+ int d = target_pages - cur_pages;
+ pod_pages += ( done < d ) ? done : d;
+ }
+ cur_pages += done;
+ count -= done;
+ }
+ }
+ }
+
/* Fall back to 4kB extents. */
if ( count != 0 )
{
rc = xc_domain_memory_populate_physmap(
xc_handle, dom, count, 0, 0, &page_array[cur_pages]);
cur_pages += count;
+ stats_normal_pages += count;
if ( pod_mode )
pod_pages -= count;
}
@@ -241,6 +303,12 @@ static int setup_guest(int xc_handle,
goto error_out;
}
+ IPRINTF("PHYSICAL MEMORY ALLOCATION:\n"
+ " 4KB PAGES: 0x%016lx\n"
+ " 2MB PAGES: 0x%016lx\n"
+ " 1GB PAGES: 0x%016lx\n",
+ stats_normal_pages, stats_2mb_pages, stats_1gb_pages);
+
if ( loadelfimage(&elf, xc_handle, dom, page_array) != 0 )
goto error_out;
[-- Attachment #3: 1gb_detect.patch --]
[-- Type: application/octet-stream, Size: 2189 bytes --]
# HG changeset patch
# User root@weisles1064.amd.com
# Date 1236802340 18000
# Node ID faf8efbc205d9354b947e74921fa4c701dfff822
# Parent 993b10a7eaa4b3342fa5e0f4c558386445c6ea04
add 1gb detection code
diff -r 993b10a7eaa4 -r faf8efbc205d xen/arch/x86/hvm/svm/svm.c
--- a/xen/arch/x86/hvm/svm/svm.c Wed Mar 11 13:48:21 2009 -0500
+++ b/xen/arch/x86/hvm/svm/svm.c Wed Mar 11 15:12:20 2009 -0500
@@ -872,6 +872,7 @@ int start_svm(struct cpuinfo_x86 *c)
cpuid_edx(0x8000000A) : 0);
svm_function_table.hap_supported = cpu_has_svm_npt;
+ svm_function_table.hap_1gb_pgtb = (cpuid_edx(0x80000001) & 0x04000000)?1:0;
hvm_enable(&svm_function_table);
diff -r 993b10a7eaa4 -r faf8efbc205d xen/arch/x86/hvm/vmx/vmx.c
--- a/xen/arch/x86/hvm/vmx/vmx.c Wed Mar 11 13:48:21 2009 -0500
+++ b/xen/arch/x86/hvm/vmx/vmx.c Wed Mar 11 15:12:20 2009 -0500
@@ -1416,6 +1416,8 @@ void start_vmx(void)
vmx_function_table.hap_supported = 1;
}
+ vmx_function_table.hap_1gb_pgtb = 0;
+
if ( cpu_has_vmx_vpid )
{
printk("VMX: VPID is available.\n");
diff -r 993b10a7eaa4 -r faf8efbc205d xen/arch/x86/mm/p2m.c
--- a/xen/arch/x86/mm/p2m.c Wed Mar 11 13:48:21 2009 -0500
+++ b/xen/arch/x86/mm/p2m.c Wed Mar 11 15:12:20 2009 -0500
@@ -1642,7 +1642,8 @@ int set_p2m_entry(struct domain *d, unsi
while ( todo )
{
- order = ( (((gfn | mfn_x(mfn) | todo) & ((1ul << 18) - 1)) == 0) ) ?
+ order = ( (((gfn | mfn_x(mfn) | todo) & ((1ul << 18) - 1)) == 0) &&
+ hvm_funcs.hap_1gb_pgtb ) ?
18 : (((gfn | mfn_x(mfn) | todo) & ((1ul << 9) - 1)) == 0) ?
9 : 0;
rc = d->arch.p2m->set_entry(d, gfn, mfn, order, p2mt);
diff -r 993b10a7eaa4 -r faf8efbc205d xen/include/asm-x86/hvm/hvm.h
--- a/xen/include/asm-x86/hvm/hvm.h Wed Mar 11 13:48:21 2009 -0500
+++ b/xen/include/asm-x86/hvm/hvm.h Wed Mar 11 15:12:20 2009 -0500
@@ -65,6 +65,9 @@ struct hvm_function_table {
/* Support Hardware-Assisted Paging? */
int hap_supported;
+
+ /* Support 1GB Harware-Assisted Paging? */
+ int hap_1gb_pgtb;
/*
* Initialise/destroy HVM domain/vcpu resources
[-- Attachment #4: 1gb_p2m.patch --]
[-- Type: application/octet-stream, Size: 12272 bytes --]
diff -r e821a12d92a9 -r 993b10a7eaa4 xen/arch/x86/mm/p2m.c
--- a/xen/arch/x86/mm/p2m.c Wed Mar 11 06:25:58 2009 -0500
+++ b/xen/arch/x86/mm/p2m.c Wed Mar 11 13:48:21 2009 -0500
@@ -207,7 +207,36 @@ p2m_next_level(struct domain *d, mfn_t *
ASSERT(l1e_get_flags(*p2m_entry) & (_PAGE_PRESENT|_PAGE_PSE));
- /* split single large page into 4KB page in P2M table */
+ /* split 1GB page into 2MB pages in P2M table */
+ if ( type == PGT_l2_page_table && (l1e_get_flags(*p2m_entry) & _PAGE_PSE) )
+ {
+ unsigned long flags, pfn;
+ struct page_info *pg = d->arch.p2m->alloc_page(d);
+ if ( pg == NULL )
+ return 0;
+ page_list_add_tail(pg, &d->arch.p2m->pages);
+ pg->u.inuse.type_info = PGT_l1_page_table | 1 | PGT_validated;
+ pg->count_info = 1;
+
+ flags = l1e_get_flags(*p2m_entry);
+ pfn = l1e_get_pfn(*p2m_entry);
+
+ l1_entry = map_domain_page(mfn_x(page_to_mfn(pg)));
+ for ( i = 0; i < L2_PAGETABLE_ENTRIES; i++ )
+ {
+ new_entry = l1e_from_pfn(pfn + (i * L1_PAGETABLE_ENTRIES), flags);
+ paging_write_p2m_entry(d, gfn, l1_entry+i, *table_mfn, new_entry,
+ 2);
+ }
+ unmap_domain_page(l1_entry);
+ new_entry = l1e_from_pfn(mfn_x(page_to_mfn(pg)),
+ __PAGE_HYPERVISOR|_PAGE_USER); //disable PSE
+ paging_write_p2m_entry(d, gfn,
+ p2m_entry, *table_mfn, new_entry, 3);
+ }
+
+
+ /* split single 2MB page into 4KB page in P2M table */
if ( type == PGT_l1_page_table && (l1e_get_flags(*p2m_entry) & _PAGE_PSE) )
{
unsigned long flags, pfn;
@@ -1020,6 +1049,19 @@ p2m_pod_demand_populate(struct domain *d
return 0;
}
+ /* Because PoD does not have cache list for 1GB pages, it has to remap
+ * 1GB region to 2MB chunks for a retry. */
+ if ( order == 18 )
+ {
+ gfn_aligned = (gfn>>order)<<order;
+ for( i=0; i<(1<<order); i+=(1<<9) )
+ set_p2m_entry(d, gfn_aligned+i, _mfn(POPULATE_ON_DEMAND_MFN), 9,
+ p2m_populate_on_demand);
+ audit_p2m(d);
+ p2m_unlock(p2md);
+ return 0;
+ }
+
/* If we're low, start a sweep */
if ( order == 9 && page_list_empty(&p2md->pod.super) )
p2m_pod_emergency_sweep_super(d);
@@ -1116,6 +1158,7 @@ p2m_set_entry(struct domain *d, unsigned
l1_pgentry_t *p2m_entry;
l1_pgentry_t entry_content;
l2_pgentry_t l2e_content;
+ l3_pgentry_t l3e_content;
int rv=0;
#if CONFIG_PAGING_LEVELS >= 4
@@ -1125,18 +1168,45 @@ p2m_set_entry(struct domain *d, unsigned
goto out;
#endif
/*
+ * Try to allocate 1GB page table if this feature is available.
+ *
* When using PAE Xen, we only allow 33 bits of pseudo-physical
* address in translated guests (i.e. 8 GBytes). This restriction
* comes from wanting to map the P2M table into the 16MB RO_MPT hole
* in Xen's address space for translated PV guests.
* When using AMD's NPT on PAE Xen, we are restricted to 4GB.
*/
- if ( !p2m_next_level(d, &table_mfn, &table, &gfn_remainder, gfn,
- L3_PAGETABLE_SHIFT - PAGE_SHIFT,
- ((CONFIG_PAGING_LEVELS == 3)
- ? (d->arch.hvm_domain.hap_enabled ? 4 : 8)
- : L3_PAGETABLE_ENTRIES),
- PGT_l2_page_table) )
+ if ( page_order == 18 )
+ {
+ p2m_entry = p2m_find_entry(table, &gfn_remainder, gfn,
+ L3_PAGETABLE_SHIFT - PAGE_SHIFT,
+ L3_PAGETABLE_ENTRIES);
+ ASSERT(p2m_entry);
+
+ if ( (l1e_get_flags(*p2m_entry) & _PAGE_PRESENT) &&
+ !(l1e_get_flags(*p2m_entry) & _PAGE_PSE) )
+ {
+ P2M_ERROR("configure P2M table L3 entry with large page\n");
+ domain_crash(d);
+ goto out;
+ }
+
+ if ( mfn_valid(mfn) || p2m_is_magic(p2mt) )
+ l3e_content = l3e_from_pfn(mfn_x(mfn),
+ p2m_type_to_flags(p2mt) | _PAGE_PSE);
+ else
+ l3e_content = l3e_empty();
+
+ entry_content.l1 = l3e_content.l3;
+ paging_write_p2m_entry(d, gfn, p2m_entry, table_mfn, entry_content, 3);
+
+ }
+ else if ( !p2m_next_level(d, &table_mfn, &table, &gfn_remainder, gfn,
+ L3_PAGETABLE_SHIFT - PAGE_SHIFT,
+ ((CONFIG_PAGING_LEVELS == 3)
+ ? (d->arch.hvm_domain.hap_enabled ? 4 : 8)
+ : L3_PAGETABLE_ENTRIES),
+ PGT_l2_page_table) )
goto out;
if ( page_order == 0 )
@@ -1158,7 +1228,7 @@ p2m_set_entry(struct domain *d, unsigned
/* level 1 entry */
paging_write_p2m_entry(d, gfn, p2m_entry, table_mfn, entry_content, 1);
}
- else
+ else if ( page_order == 9 )
{
p2m_entry = p2m_find_entry(table, &gfn_remainder, gfn,
L2_PAGETABLE_SHIFT - PAGE_SHIFT,
@@ -1255,10 +1325,32 @@ p2m_gfn_to_mfn(struct domain *d, unsigne
#else
l3e += l3_table_offset(addr);
#endif
+pod_retry_l3:
if ( (l3e_get_flags(*l3e) & _PAGE_PRESENT) == 0 )
{
+ if ( p2m_flags_to_type(l3e_get_flags(*l3e)) ==
+ p2m_populate_on_demand )
+ {
+ if ( q != p2m_query ) {
+ if ( !p2m_pod_demand_populate(d, gfn, mfn,
+ (l1_pgentry_t *)l3e, 18, q) )
+ goto pod_retry_l3;
+ }
+ else
+ *t = p2m_populate_on_demand;
+ }
unmap_domain_page(l3e);
return _mfn(INVALID_MFN);
+ }
+ else if ( (l3e_get_flags(*l3e) & _PAGE_PSE ) )
+ {
+ mfn = _mfn(l3e_get_pfn(*l3e) +
+ l2_table_offset(addr) * L1_PAGETABLE_ENTRIES +
+ l1_table_offset(addr));
+ unmap_domain_page(l3e);
+
+ ASSERT(mfn_valid(mfn) || !p2m_is_ram(*t));
+ return p2m_is_valid(*t) ? mfn : _mfn(INVALID_MFN);
}
mfn = _mfn(l3e_get_pfn(*l3e));
unmap_domain_page(l3e);
@@ -1340,10 +1432,60 @@ static mfn_t p2m_gfn_to_mfn_current(unsi
{
l1_pgentry_t l1e = l1e_empty(), *p2m_entry;
l2_pgentry_t l2e = l2e_empty();
+ l3_pgentry_t l3e = l3e_empty();
int ret;
ASSERT(gfn < (RO_MPT_VIRT_END - RO_MPT_VIRT_START)
/ sizeof(l1_pgentry_t));
+
+ /* Read and process L3 */
+ p2m_entry = (l1_pgentry_t *)
+ &__linear_l2_table[l2_linear_offset(RO_MPT_VIRT_START)
+ + l3_linear_offset(addr)];
+ pod_retry_l3:
+ ret = __copy_from_user(&l3e,
+ p2m_entry,
+ sizeof(l3e));
+ if ( ret != 0 || !(l3e_get_flags(l3e) & _PAGE_PRESENT) )
+ {
+ if ( (l3e_get_flags(l3e) & _PAGE_PSE)
+ && ( p2m_flags_to_type(l3e_get_flags(l3e))
+ == p2m_populate_on_demand ) )
+ {
+ if ( q != p2m_query )
+ {
+ if( !p2m_pod_demand_populate(current->domain, gfn, mfn,
+ p2m_entry, 18, q) )
+ goto pod_retry_l3;
+
+ /* Allocate failed. */
+ p2mt = p2m_invalid;
+ printk("%s: Allocate failed!\n", __func__);
+ goto out;
+ }
+ else
+ {
+ p2mt = p2m_populate_on_demand;
+ goto out;
+ }
+ }
+
+ goto pod_retry_l2;
+ }
+
+ if ( l3e_get_flags(l3e) & _PAGE_PSE )
+ {
+ p2mt = p2m_flags_to_type(l3e_get_flags(l3e));
+ ASSERT(l3e_get_pfn(l3e) != INVALID_MFN || !p2m_is_ram(p2mt));
+ if (p2m_is_valid(p2mt) )
+ mfn = _mfn(l3e_get_pfn(l3e) +
+ l2_table_offset(addr) * L1_PAGETABLE_ENTRIES +
+ l1_table_offset(addr));
+ else
+ p2mt = p2m_mmio_dm;
+
+ goto out;
+ }
/*
* Read & process L2
@@ -1499,7 +1641,10 @@ int set_p2m_entry(struct domain *d, unsi
while ( todo )
{
- order = (((gfn | mfn_x(mfn) | todo) & ((1ul << 9) - 1)) == 0) ? 9 : 0;
+
+ order = ( (((gfn | mfn_x(mfn) | todo) & ((1ul << 18) - 1)) == 0) ) ?
+ 18 : (((gfn | mfn_x(mfn) | todo) & ((1ul << 9) - 1)) == 0) ?
+ 9 : 0;
rc = d->arch.p2m->set_entry(d, gfn, mfn, order, p2mt);
gfn += 1ul << order;
if ( mfn_x(mfn) != INVALID_MFN )
@@ -1752,6 +1897,31 @@ static void audit_p2m(struct domain *d)
gfn += 1 << (L3_PAGETABLE_SHIFT - PAGE_SHIFT);
continue;
}
+
+ /* check for 1GB super page */
+ if ( l3e_get_flags(l3e[i3]) & _PAGE_PSE )
+ {
+ mfn = l3e_get_pfn(l3e[i3]);
+ ASSERT(mfn_valid(_mfn(mfn)));
+ /* we have to cover 512x512 4K pages */
+ for ( i2 = 0;
+ i2 < (L2_PAGETABLE_ENTRIES * L1_PAGETABLE_ENTRIES);
+ i2++)
+ {
+ m2pfn = get_gpfn_from_mfn(mfn+i2);
+ if ( m2pfn != (gfn + i2) )
+ {
+ pmbad++;
+ P2M_PRINTK("mismatch: gfn %#lx -> mfn %#lx"
+ " -> gfn %#lx\n", gfn+i2, mfn+i2,
+ m2pfn);
+ BUG();
+ }
+ gfn += 1 << (L3_PAGETABLE_SHIFT - PAGE_SHIFT);
+ continue;
+ }
+ }
+
l2e = map_domain_page(mfn_x(_mfn(l3e_get_pfn(l3e[i3]))));
for ( i2 = 0; i2 < L2_PAGETABLE_ENTRIES; i2++ )
{
@@ -2080,7 +2250,7 @@ void p2m_change_type_global(struct domai
l1_pgentry_t l1e_content;
l1_pgentry_t *l1e;
l2_pgentry_t *l2e;
- mfn_t l1mfn, l2mfn;
+ mfn_t l1mfn, l2mfn, l3mfn;
int i1, i2;
l3_pgentry_t *l3e;
int i3;
@@ -2100,6 +2270,7 @@ void p2m_change_type_global(struct domai
#if CONFIG_PAGING_LEVELS == 4
l4e = map_domain_page(mfn_x(pagetable_get_mfn(d->arch.phys_table)));
#else /* CONFIG_PAGING_LEVELS == 3 */
+ l3mfn = _mfn(mfn_x(pagetable_get_mfn(d->arch.phys_table)));
l3e = map_domain_page(mfn_x(pagetable_get_mfn(d->arch.phys_table)));
#endif
@@ -2110,6 +2281,7 @@ void p2m_change_type_global(struct domai
{
continue;
}
+ l3mfn = _mfn(l4e_get_pfn(l4e[i4]));
l3e = map_domain_page(l4e_get_pfn(l4e[i4]));
#endif
for ( i3 = 0;
@@ -2120,6 +2292,21 @@ void p2m_change_type_global(struct domai
{
continue;
}
+
+ if ( (l3e_get_flags(l3e[i3]) & _PAGE_PSE) )
+ {
+ flags = l3e_get_flags(l3e[i3]);
+ if ( p2m_flags_to_type(flags) != ot )
+ continue;
+ mfn = l3e_get_pfn(l3e[i3]);
+ gfn = get_gpfn_from_mfn(mfn);
+ flags = p2m_type_to_flags(nt);
+ l1e_content = l1e_from_pfn(mfn, flags | _PAGE_PSE);
+ paging_write_p2m_entry(d, gfn, (l1_pgentry_t *)&l3e[i3],
+ l3mfn, l1e_content, 3);
+ continue;
+ }
+
l2mfn = _mfn(l3e_get_pfn(l3e[i3]));
l2e = map_domain_page(l3e_get_pfn(l3e[i3]));
for ( i2 = 0; i2 < L2_PAGETABLE_ENTRIES; i2++ )
[-- Attachment #5: Type: text/plain, Size: 138 bytes --]
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
^ permalink raw reply [flat|nested] 23+ messages in thread* RE: [RFC][Patches] Xen 1GB Page Table Support
2009-03-19 8:07 ` Huang2, Wei
@ 2009-03-19 14:17 ` Dan Magenheimer
2009-03-19 18:51 ` Wei Huang
2009-05-19 0:55 ` Keir Fraser
2010-01-13 4:07 ` Xu, Dongxiao
2 siblings, 1 reply; 23+ messages in thread
From: Dan Magenheimer @ 2009-03-19 14:17 UTC (permalink / raw)
To: Huang2, Wei, George Dunlap; +Cc: xen-devel, keir.fraser, Tim Deegan
I'd like to reiterate my argument raised in a previous
discussion of hugepages: Just because this CAN be made
to work, doesn't imply that it SHOULD be made to work.
Real users use larger pages in their OS for the sole
reason that they expect a performance improvement.
If it magically works, but works slow (and possibly
slower than if the OS had just used small pages to
start with), this is likely to lead to unsatisfied
customers, and perhaps allegations such as "Xen sucks
when running databases".
So, please, let's think this through before implementing
it just because we can. At a minimum, an administrator
should be somehow warned if large pages are getting splintered.
And if its going in over my objection, please tie it to
a boot option that defaults off so administrator action
is required to allow silent splintering.
My two cents...
Dan
> -----Original Message-----
> From: Huang2, Wei [mailto:Wei.Huang2@amd.com]
> Sent: Thursday, March 19, 2009 2:07 AM
> To: George Dunlap
> Cc: xen-devel@lists.xensource.com; keir.fraser@eu.citrix.com;
> Tim Deegan
> Subject: RE: [Xen-devel] [RFC][Patches] Xen 1GB Page Table Support
>
>
> Here are patches using the middle approach. It handles 1GB
> pages in PoD
> by remapping 1GB with 2MB pages & retry. I also added code for 1GB
> detection. Please comment.
>
> Thanks a lot,
>
> -Wei
>
> -----Original Message-----
> From: dunlapg@gmail.com [mailto:dunlapg@gmail.com] On Behalf Of George
> Dunlap
> Sent: Wednesday, March 18, 2009 12:20 PM
> To: Huang2, Wei
> Cc: xen-devel@lists.xensource.com; keir.fraser@eu.citrix.com;
> Tim Deegan
> Subject: Re: [Xen-devel] [RFC][Patches] Xen 1GB Page Table Support
>
> Thanks for doing this work, Wei -- especially all the extra effort for
> the PoD integration.
>
> One question: How well would you say you've tested the PoD
> functionality? Or to put it the other way, how much do I need to
> prioritize testing this before the 3.4 release?
>
> It wouldn't be a bad idea to do as you suggested, and break things
> into 2 meg pages for the PoD case. In order to take the best
> advantage of this in a PoD scenario, you'd need to have a balloon
> driver that could allocate 1G of continuous *guest* p2m space, which
> seems a bit optimistic at this point...
>
> -George
>
> 2009/3/18 Huang2, Wei <Wei.Huang2@amd.com>:
> > Current Xen supports 2MB super pages for NPT/EPT. The
> attached patches
> > extend this feature to support 1GB pages. The PoD
> (populate-on-demand)
> > introduced by George Dunlap made P2M modification harder. I tried to
> > preserve existing PoD design by introducing a 1GB PoD cache list.
> >
> >
> >
> > Note that 1GB PoD can be dropped if we don't care about 1GB when PoD
> is
> > enabled. In this case, we can just split 1GB PDPE into 512x2MB PDE
> entries
> > and grab pages from PoD super list. That can pretty much make
> > 1gb_p2m_pod.patch go away.
> >
> >
> >
> > Any comment/suggestion on design idea will be appreciated.
> >
> >
> >
> > Thanks,
> >
> >
> >
> > -Wei
> >
> >
> >
> >
> >
> > The following is the description:
> >
> > === 1gb_tools.patch ===
> >
> > Extend existing setup_guest() function. Basically, it tries to
> allocate 1GB
> > pages whenever available. If this request fails, it falls
> back to 2MB.
> If
> > both fail, then 4KB pages will be used.
> >
> >
> >
> > === 1gb_p2m.patch ===
> >
> > * p2m_next_level()
> >
> > Check PSE bit of L3 page table entry. If 1GB is found (PSE=1), we
> split 1GB
> > into 512 2MB pages.
> >
> >
> >
> > * p2m_set_entry()
> >
> > Configure the PSE bit of L3 P2M table if page order == 18 (1GB).
> >
> >
> >
> > * p2m_gfn_to_mfn()
> >
> > Add support for 1GB case when doing gfn to mfn translation. When L3
> entry is
> > marked as POPULATE_ON_DEMAND, we call 2m_pod_demand_populate().
> Otherwise,
> > we do the regular address translation (gfn ==> mfn).
> >
> >
> >
> > * p2m_gfn_to_mfn_current()
> >
> > This is similar to p2m_gfn_to_mfn(). When L3 entry s marked as
> > POPULATE_ON_DEMAND, it demands a populate using
> p2m_pod_demand_populate().
> > Otherwise, it does a normal translation. 1GB page is taken into
> > consideration.
> >
> >
> >
> > * set_p2m_entry()
> >
> > Request 1GB page
> >
> >
> >
> > * audit_p2m()
> >
> > Support 1GB while auditing p2m table.
> >
> >
> >
> > * p2m_change_type_global()
> >
> > Deal with 1GB page when changing global page type.
> >
> >
> >
> > === 1gb_p2m_pod.patch ===
> >
> > * xen/include/asm-x86/p2m.h
> >
> > Minor change to deal with PoD. It separates super page
> cache list into
> 2MB
> > and 1GB lists. Similarly, we record last gpfn of sweeping
> for both 2MB
> and
> > 1GB.
> >
> >
> >
> > * p2m_pod_cache_add()
> >
> > Check page order and add 1GB super page into PoD 1GB cache list.
> >
> >
> >
> > * p2m_pod_cache_get()
> >
> > Grab a page from cache list. It tries to break 1GB page into 512 2MB
> pages
> > if 2MB PoD list is empty. Similarly, 4KB can be requested from super
> pages.
> > The breaking order is 2MB then 1GB.
> >
> >
> >
> > * p2m_pod_cache_target()
> >
> > This function is used to set PoD cache size. To increase PoD target,
> we try
> > to allocate 1GB from xen domheap. If this fails, we try 2MB. If both
> fail,
> > we try 4KB which is guaranteed to work.
> >
> >
> >
> > To decrease the target, we use a similar approach. We first try to
> free 1GB
> > pages from 1GB PoD cache list. If such request fails, we try 2MB PoD
> cache
> > list. If both fail, we try 4KB list.
> >
> >
> >
> > * p2m_pod_zero_check_superpage_1gb()
> >
> > This adds a new function to check for 1GB page. This function is
> similar to
> > p2m_pod_zero_check_superpage_2mb().
> >
> >
> >
> > * p2m_pod_zero_check_superpage_1gb()
> >
> > We add a new function to sweep 1GB page from guest memory.
> This is the
> same
> > as p2m_pod_zero_check_superpage_2mb().
> >
> >
> >
> > * p2m_pod_demand_populate()
> >
> > The trick of this function is to do remap_and_retry if
> p2m_pod_cache_get()
> > fails. When p2m_pod_get() fails, this function will splits p2m table
> entry
> > into smaller ones (e.g. 1GB ==> 2MB or 2MB ==> 4KB). That can
> guarantee
> > populate demands always work.
> >
> >
> >
> >
> >
> > _______________________________________________
> > Xen-devel mailing list
> > Xen-devel@lists.xensource.com
> > http://lists.xensource.com/xen-devel
> >
> >
>
>
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [RFC][Patches] Xen 1GB Page Table Support
2009-03-19 14:17 ` Dan Magenheimer
@ 2009-03-19 18:51 ` Wei Huang
2009-03-19 19:56 ` Dan Magenheimer
0 siblings, 1 reply; 23+ messages in thread
From: Wei Huang @ 2009-03-19 18:51 UTC (permalink / raw)
To: Dan Magenheimer; +Cc: George Dunlap, xen-devel, keir.fraser, Tim Deegan
Dan,
Thanks for your comments. I am not sure about which splintering overhead
you are referring to. I can think of three areas:
1. splintering in page allocation
In this case, Xen fails to allocate requested page order. So it falls
back to smaller pages to setup p2m table. The overhead is
O(guest_mem_size), which is a one-time deal.
2. P2M splits large page into smaller pages
This is one directional because we don't merge smaller pages to large
ones. The worst case is to split all guest large pages. So overhead is
O(total_large_page_mem). In long run, the overhead will converge to 0
because it is one-directional. Note this overhead also covers when PoD
feature is enabled.
3. CPU splintering
If CPU does not support 1GB page, it automatically does splintering
using smaller ones (such as 2MB). In this case, the overhead is always
there. But 1) this only happens to a small number of old chips; 2) I
believe that it is still faster than 4K pages. CPUID (1gb feature and
1gb TLB entries) can be used to detect and stop this problem, if we
don't really like it.
I agree on your concerns. Customers should have the right to make their
own decision. But that require new feature is enabled in the first
place. For a lot of benchmarks, splintering overhead can be offset with
benefits of huge pages. SPECJBB is a good example of using large pages
(see Ben Serebrin's presentation in Xen Summit). With that said, I agree
with the idea of adding a new option in guest configure file.
-Wei
Dan Magenheimer wrote:
> I'd like to reiterate my argument raised in a previous
> discussion of hugepages: Just because this CAN be made
> to work, doesn't imply that it SHOULD be made to work.
> Real users use larger pages in their OS for the sole
> reason that they expect a performance improvement.
> If it magically works, but works slow (and possibly
> slower than if the OS had just used small pages to
> start with), this is likely to lead to unsatisfied
> customers, and perhaps allegations such as "Xen sucks
> when running databases".
>
> So, please, let's think this through before implementing
> it just because we can. At a minimum, an administrator
> should be somehow warned if large pages are getting splintered.
>
> And if its going in over my objection, please tie it to
> a boot option that defaults off so administrator action
> is required to allow silent splintering.
>
> My two cents...
> Dan
>
>> -----Original Message-----
>> From: Huang2, Wei [mailto:Wei.Huang2@amd.com]
>> Sent: Thursday, March 19, 2009 2:07 AM
>> To: George Dunlap
>> Cc: xen-devel@lists.xensource.com; keir.fraser@eu.citrix.com;
>> Tim Deegan
>> Subject: RE: [Xen-devel] [RFC][Patches] Xen 1GB Page Table Support
>>
>>
>> Here are patches using the middle approach. It handles 1GB
>> pages in PoD
>> by remapping 1GB with 2MB pages & retry. I also added code for 1GB
>> detection. Please comment.
>>
>> Thanks a lot,
>>
>> -Wei
>>
>> -----Original Message-----
>> From: dunlapg@gmail.com [mailto:dunlapg@gmail.com] On Behalf Of George
>> Dunlap
>> Sent: Wednesday, March 18, 2009 12:20 PM
>> To: Huang2, Wei
>> Cc: xen-devel@lists.xensource.com; keir.fraser@eu.citrix.com;
>> Tim Deegan
>> Subject: Re: [Xen-devel] [RFC][Patches] Xen 1GB Page Table Support
>>
>> Thanks for doing this work, Wei -- especially all the extra effort for
>> the PoD integration.
>>
>> One question: How well would you say you've tested the PoD
>> functionality? Or to put it the other way, how much do I need to
>> prioritize testing this before the 3.4 release?
>>
>> It wouldn't be a bad idea to do as you suggested, and break things
>> into 2 meg pages for the PoD case. In order to take the best
>> advantage of this in a PoD scenario, you'd need to have a balloon
>> driver that could allocate 1G of continuous *guest* p2m space, which
>> seems a bit optimistic at this point...
>>
>> -George
>>
>> 2009/3/18 Huang2, Wei <Wei.Huang2@amd.com>:
>>> Current Xen supports 2MB super pages for NPT/EPT. The
>> attached patches
>>> extend this feature to support 1GB pages. The PoD
>> (populate-on-demand)
>>> introduced by George Dunlap made P2M modification harder. I tried to
>>> preserve existing PoD design by introducing a 1GB PoD cache list.
>>>
>>>
>>>
>>> Note that 1GB PoD can be dropped if we don't care about 1GB when PoD
>> is
>>> enabled. In this case, we can just split 1GB PDPE into 512x2MB PDE
>> entries
>>> and grab pages from PoD super list. That can pretty much make
>>> 1gb_p2m_pod.patch go away.
>>>
>>>
>>>
>>> Any comment/suggestion on design idea will be appreciated.
>>>
>>>
>>>
>>> Thanks,
>>>
>>>
>>>
>>> -Wei
>>>
>>>
>>>
>>>
>>>
>>> The following is the description:
>>>
>>> === 1gb_tools.patch ===
>>>
>>> Extend existing setup_guest() function. Basically, it tries to
>> allocate 1GB
>>> pages whenever available. If this request fails, it falls
>> back to 2MB.
>> If
>>> both fail, then 4KB pages will be used.
>>>
>>>
>>>
>>> === 1gb_p2m.patch ===
>>>
>>> * p2m_next_level()
>>>
>>> Check PSE bit of L3 page table entry. If 1GB is found (PSE=1), we
>> split 1GB
>>> into 512 2MB pages.
>>>
>>>
>>>
>>> * p2m_set_entry()
>>>
>>> Configure the PSE bit of L3 P2M table if page order == 18 (1GB).
>>>
>>>
>>>
>>> * p2m_gfn_to_mfn()
>>>
>>> Add support for 1GB case when doing gfn to mfn translation. When L3
>> entry is
>>> marked as POPULATE_ON_DEMAND, we call 2m_pod_demand_populate().
>> Otherwise,
>>> we do the regular address translation (gfn ==> mfn).
>>>
>>>
>>>
>>> * p2m_gfn_to_mfn_current()
>>>
>>> This is similar to p2m_gfn_to_mfn(). When L3 entry s marked as
>>> POPULATE_ON_DEMAND, it demands a populate using
>> p2m_pod_demand_populate().
>>> Otherwise, it does a normal translation. 1GB page is taken into
>>> consideration.
>>>
>>>
>>>
>>> * set_p2m_entry()
>>>
>>> Request 1GB page
>>>
>>>
>>>
>>> * audit_p2m()
>>>
>>> Support 1GB while auditing p2m table.
>>>
>>>
>>>
>>> * p2m_change_type_global()
>>>
>>> Deal with 1GB page when changing global page type.
>>>
>>>
>>>
>>> === 1gb_p2m_pod.patch ===
>>>
>>> * xen/include/asm-x86/p2m.h
>>>
>>> Minor change to deal with PoD. It separates super page
>> cache list into
>> 2MB
>>> and 1GB lists. Similarly, we record last gpfn of sweeping
>> for both 2MB
>> and
>>> 1GB.
>>>
>>>
>>>
>>> * p2m_pod_cache_add()
>>>
>>> Check page order and add 1GB super page into PoD 1GB cache list.
>>>
>>>
>>>
>>> * p2m_pod_cache_get()
>>>
>>> Grab a page from cache list. It tries to break 1GB page into 512 2MB
>> pages
>>> if 2MB PoD list is empty. Similarly, 4KB can be requested from super
>> pages.
>>> The breaking order is 2MB then 1GB.
>>>
>>>
>>>
>>> * p2m_pod_cache_target()
>>>
>>> This function is used to set PoD cache size. To increase PoD target,
>> we try
>>> to allocate 1GB from xen domheap. If this fails, we try 2MB. If both
>> fail,
>>> we try 4KB which is guaranteed to work.
>>>
>>>
>>>
>>> To decrease the target, we use a similar approach. We first try to
>> free 1GB
>>> pages from 1GB PoD cache list. If such request fails, we try 2MB PoD
>> cache
>>> list. If both fail, we try 4KB list.
>>>
>>>
>>>
>>> * p2m_pod_zero_check_superpage_1gb()
>>>
>>> This adds a new function to check for 1GB page. This function is
>> similar to
>>> p2m_pod_zero_check_superpage_2mb().
>>>
>>>
>>>
>>> * p2m_pod_zero_check_superpage_1gb()
>>>
>>> We add a new function to sweep 1GB page from guest memory.
>> This is the
>> same
>>> as p2m_pod_zero_check_superpage_2mb().
>>>
>>>
>>>
>>> * p2m_pod_demand_populate()
>>>
>>> The trick of this function is to do remap_and_retry if
>> p2m_pod_cache_get()
>>> fails. When p2m_pod_get() fails, this function will splits p2m table
>> entry
>>> into smaller ones (e.g. 1GB ==> 2MB or 2MB ==> 4KB). That can
>> guarantee
>>> populate demands always work.
>>>
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> Xen-devel mailing list
>>> Xen-devel@lists.xensource.com
>>> http://lists.xensource.com/xen-devel
>>>
>>>
>>
>
^ permalink raw reply [flat|nested] 23+ messages in thread
* RE: [RFC][Patches] Xen 1GB Page Table Support
2009-03-19 18:51 ` Wei Huang
@ 2009-03-19 19:56 ` Dan Magenheimer
2009-03-19 21:07 ` Wei Huang
2009-03-20 9:45 ` George Dunlap
0 siblings, 2 replies; 23+ messages in thread
From: Dan Magenheimer @ 2009-03-19 19:56 UTC (permalink / raw)
To: Wei Huang; +Cc: George Dunlap, xen-devel, keir.fraser, Tim Deegan
Hi Wei --
I'm not worried about the overhead of the splintering, I'm
worried about the "hidden overhead" everytime a "silent
splinter" is used.
Let's assume three scenarios (and for now use 2MB pages though
the same concerns can be extended to 1GB and/or mixed 2MB/1GB):
A) DB code assumes 2MB pages, OS assumes 2MB pages, Xen provides
only 2MB pages (no splintering occurs)
B) DB code assumes 2MB pages, OS assumes 2MB pages, Xen provides
only 4KB pages (because of fragmentation, all 2MB pages have
been splintered)
C) DB code assumes 4KB pages, OS assumes 4KB pages, Xen provides
4KB pages
Now run some benchmarks. Clearly one would assume that A is
faster than both B and C. The question is: Is B faster or slower
than C?
If B is always faster than C, then I have less objection to
"silent splintering". But if B is sometimes (or maybe always?)
slower than C, that's a big issue because a user has gone through
the effort of choosing a better-performing system configuration
for their software (2MB DB on 2MB OS), but it actually performs
worse than if they had chosen the "lower performing" configuration.
And, worse, it will likely degrade across time so performance
might be fine when the 2MB-DB-on-2MB-OS guest is launched
but get much worse when it is paused, save/restored, migrated,
or hot-failed. So even if B is only slightly faster than C,
if B is much slower than A, this is a problem.
Does that make sense?
Some suggestions:
1) If it is possible for an administrator to determine how many
large pages (both 2MB and 1GB) were requested by each domain
and how many are currently whole-vs-splintered, that would help.
2) We may need some form of memory defragmenter
> -----Original Message-----
> From: Wei Huang [mailto:wei.huang2@amd.com]
> Sent: Thursday, March 19, 2009 12:52 PM
> To: Dan Magenheimer
> Cc: George Dunlap; xen-devel@lists.xensource.com;
> keir.fraser@eu.citrix.com; Tim Deegan
> Subject: Re: [Xen-devel] [RFC][Patches] Xen 1GB Page Table Support
>
>
> Dan,
>
> Thanks for your comments. I am not sure about which
> splintering overhead
> you are referring to. I can think of three areas:
>
> 1. splintering in page allocation
> In this case, Xen fails to allocate requested page order. So it falls
> back to smaller pages to setup p2m table. The overhead is
> O(guest_mem_size), which is a one-time deal.
>
> 2. P2M splits large page into smaller pages
> This is one directional because we don't merge smaller pages to large
> ones. The worst case is to split all guest large pages. So
> overhead is
> O(total_large_page_mem). In long run, the overhead will converge to 0
> because it is one-directional. Note this overhead also covers
> when PoD
> feature is enabled.
>
> 3. CPU splintering
> If CPU does not support 1GB page, it automatically does splintering
> using smaller ones (such as 2MB). In this case, the overhead
> is always
> there. But 1) this only happens to a small number of old chips; 2) I
> believe that it is still faster than 4K pages. CPUID (1gb feature and
> 1gb TLB entries) can be used to detect and stop this problem, if we
> don't really like it.
>
> I agree on your concerns. Customers should have the right to
> make their
> own decision. But that require new feature is enabled in the first
> place. For a lot of benchmarks, splintering overhead can be
> offset with
> benefits of huge pages. SPECJBB is a good example of using
> large pages
> (see Ben Serebrin's presentation in Xen Summit). With that
> said, I agree
> with the idea of adding a new option in guest configure file.
>
> -Wei
>
>
> Dan Magenheimer wrote:
> > I'd like to reiterate my argument raised in a previous
> > discussion of hugepages: Just because this CAN be made
> > to work, doesn't imply that it SHOULD be made to work.
> > Real users use larger pages in their OS for the sole
> > reason that they expect a performance improvement.
> > If it magically works, but works slow (and possibly
> > slower than if the OS had just used small pages to
> > start with), this is likely to lead to unsatisfied
> > customers, and perhaps allegations such as "Xen sucks
> > when running databases".
> >
> > So, please, let's think this through before implementing
> > it just because we can. At a minimum, an administrator
> > should be somehow warned if large pages are getting splintered.
> >
> > And if its going in over my objection, please tie it to
> > a boot option that defaults off so administrator action
> > is required to allow silent splintering.
> >
> > My two cents...
> > Dan
> >
> >> -----Original Message-----
> >> From: Huang2, Wei [mailto:Wei.Huang2@amd.com]
> >> Sent: Thursday, March 19, 2009 2:07 AM
> >> To: George Dunlap
> >> Cc: xen-devel@lists.xensource.com; keir.fraser@eu.citrix.com;
> >> Tim Deegan
> >> Subject: RE: [Xen-devel] [RFC][Patches] Xen 1GB Page Table Support
> >>
> >>
> >> Here are patches using the middle approach. It handles 1GB
> >> pages in PoD
> >> by remapping 1GB with 2MB pages & retry. I also added code for 1GB
> >> detection. Please comment.
> >>
> >> Thanks a lot,
> >>
> >> -Wei
> >>
> >> -----Original Message-----
> >> From: dunlapg@gmail.com [mailto:dunlapg@gmail.com] On
> Behalf Of George
> >> Dunlap
> >> Sent: Wednesday, March 18, 2009 12:20 PM
> >> To: Huang2, Wei
> >> Cc: xen-devel@lists.xensource.com; keir.fraser@eu.citrix.com;
> >> Tim Deegan
> >> Subject: Re: [Xen-devel] [RFC][Patches] Xen 1GB Page Table Support
> >>
> >> Thanks for doing this work, Wei -- especially all the
> extra effort for
> >> the PoD integration.
> >>
> >> One question: How well would you say you've tested the PoD
> >> functionality? Or to put it the other way, how much do I need to
> >> prioritize testing this before the 3.4 release?
> >>
> >> It wouldn't be a bad idea to do as you suggested, and break things
> >> into 2 meg pages for the PoD case. In order to take the best
> >> advantage of this in a PoD scenario, you'd need to have a balloon
> >> driver that could allocate 1G of continuous *guest* p2m
> space, which
> >> seems a bit optimistic at this point...
> >>
> >> -George
> >>
> >> 2009/3/18 Huang2, Wei <Wei.Huang2@amd.com>:
> >>> Current Xen supports 2MB super pages for NPT/EPT. The
> >> attached patches
> >>> extend this feature to support 1GB pages. The PoD
> >> (populate-on-demand)
> >>> introduced by George Dunlap made P2M modification harder.
> I tried to
> >>> preserve existing PoD design by introducing a 1GB PoD cache list.
> >>>
> >>>
> >>>
> >>> Note that 1GB PoD can be dropped if we don't care about
> 1GB when PoD
> >> is
> >>> enabled. In this case, we can just split 1GB PDPE into 512x2MB PDE
> >> entries
> >>> and grab pages from PoD super list. That can pretty much make
> >>> 1gb_p2m_pod.patch go away.
> >>>
> >>>
> >>>
> >>> Any comment/suggestion on design idea will be appreciated.
> >>>
> >>>
> >>>
> >>> Thanks,
> >>>
> >>>
> >>>
> >>> -Wei
> >>>
> >>>
> >>>
> >>>
> >>>
> >>> The following is the description:
> >>>
> >>> === 1gb_tools.patch ===
> >>>
> >>> Extend existing setup_guest() function. Basically, it tries to
> >> allocate 1GB
> >>> pages whenever available. If this request fails, it falls
> >> back to 2MB.
> >> If
> >>> both fail, then 4KB pages will be used.
> >>>
> >>>
> >>>
> >>> === 1gb_p2m.patch ===
> >>>
> >>> * p2m_next_level()
> >>>
> >>> Check PSE bit of L3 page table entry. If 1GB is found (PSE=1), we
> >> split 1GB
> >>> into 512 2MB pages.
> >>>
> >>>
> >>>
> >>> * p2m_set_entry()
> >>>
> >>> Configure the PSE bit of L3 P2M table if page order == 18 (1GB).
> >>>
> >>>
> >>>
> >>> * p2m_gfn_to_mfn()
> >>>
> >>> Add support for 1GB case when doing gfn to mfn
> translation. When L3
> >> entry is
> >>> marked as POPULATE_ON_DEMAND, we call 2m_pod_demand_populate().
> >> Otherwise,
> >>> we do the regular address translation (gfn ==> mfn).
> >>>
> >>>
> >>>
> >>> * p2m_gfn_to_mfn_current()
> >>>
> >>> This is similar to p2m_gfn_to_mfn(). When L3 entry s marked as
> >>> POPULATE_ON_DEMAND, it demands a populate using
> >> p2m_pod_demand_populate().
> >>> Otherwise, it does a normal translation. 1GB page is taken into
> >>> consideration.
> >>>
> >>>
> >>>
> >>> * set_p2m_entry()
> >>>
> >>> Request 1GB page
> >>>
> >>>
> >>>
> >>> * audit_p2m()
> >>>
> >>> Support 1GB while auditing p2m table.
> >>>
> >>>
> >>>
> >>> * p2m_change_type_global()
> >>>
> >>> Deal with 1GB page when changing global page type.
> >>>
> >>>
> >>>
> >>> === 1gb_p2m_pod.patch ===
> >>>
> >>> * xen/include/asm-x86/p2m.h
> >>>
> >>> Minor change to deal with PoD. It separates super page
> >> cache list into
> >> 2MB
> >>> and 1GB lists. Similarly, we record last gpfn of sweeping
> >> for both 2MB
> >> and
> >>> 1GB.
> >>>
> >>>
> >>>
> >>> * p2m_pod_cache_add()
> >>>
> >>> Check page order and add 1GB super page into PoD 1GB cache list.
> >>>
> >>>
> >>>
> >>> * p2m_pod_cache_get()
> >>>
> >>> Grab a page from cache list. It tries to break 1GB page
> into 512 2MB
> >> pages
> >>> if 2MB PoD list is empty. Similarly, 4KB can be requested
> from super
> >> pages.
> >>> The breaking order is 2MB then 1GB.
> >>>
> >>>
> >>>
> >>> * p2m_pod_cache_target()
> >>>
> >>> This function is used to set PoD cache size. To increase
> PoD target,
> >> we try
> >>> to allocate 1GB from xen domheap. If this fails, we try
> 2MB. If both
> >> fail,
> >>> we try 4KB which is guaranteed to work.
> >>>
> >>>
> >>>
> >>> To decrease the target, we use a similar approach. We first try to
> >> free 1GB
> >>> pages from 1GB PoD cache list. If such request fails, we
> try 2MB PoD
> >> cache
> >>> list. If both fail, we try 4KB list.
> >>>
> >>>
> >>>
> >>> * p2m_pod_zero_check_superpage_1gb()
> >>>
> >>> This adds a new function to check for 1GB page. This function is
> >> similar to
> >>> p2m_pod_zero_check_superpage_2mb().
> >>>
> >>>
> >>>
> >>> * p2m_pod_zero_check_superpage_1gb()
> >>>
> >>> We add a new function to sweep 1GB page from guest memory.
> >> This is the
> >> same
> >>> as p2m_pod_zero_check_superpage_2mb().
> >>>
> >>>
> >>>
> >>> * p2m_pod_demand_populate()
> >>>
> >>> The trick of this function is to do remap_and_retry if
> >> p2m_pod_cache_get()
> >>> fails. When p2m_pod_get() fails, this function will
> splits p2m table
> >> entry
> >>> into smaller ones (e.g. 1GB ==> 2MB or 2MB ==> 4KB). That can
> >> guarantee
> >>> populate demands always work.
> >>>
> >>>
> >>>
> >>>
> >>>
> >>> _______________________________________________
> >>> Xen-devel mailing list
> >>> Xen-devel@lists.xensource.com
> >>> http://lists.xensource.com/xen-devel
> >>>
> >>>
> >>
> >
>
>
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [RFC][Patches] Xen 1GB Page Table Support
2009-03-19 19:56 ` Dan Magenheimer
@ 2009-03-19 21:07 ` Wei Huang
2009-03-20 9:45 ` George Dunlap
1 sibling, 0 replies; 23+ messages in thread
From: Wei Huang @ 2009-03-19 21:07 UTC (permalink / raw)
To: Dan Magenheimer; +Cc: George Dunlap, xen-devel, keir.fraser, Tim Deegan
Dan,
Regarding the concern of 2MBx4KB vs. 4KBx4KB, here is one paper can
"partially" decode it:
http://www.amd64.org/fileadmin/user_upload/pub/p26-bhargava.pdf
Figure 3 shows that the distribution in 2D page table walk reference.
Compared with 4KBx4KB, 2MBx4KB can eliminate the whole line of gL1,
which contributes significantly to the total walk.
The only concern is the degradation from TLB flush (invlpg) because 512
4KB TLB entries are required to back 1 2MB entry. The stress on CPU TLB
is higher in this case. But our design team believes that it isn't very
frequent.
I agree that the best case is to avoid splintering. So defragment is a
good feature to have in the future, although it requires lots of rework
on Xen MMU. Regarding Your first suggestion, it is actually easy to
implement. We can put some statistical counters into p2m code and print
out whenever needed.
-Wei
Dan Magenheimer wrote:
> Hi Wei --
>
> I'm not worried about the overhead of the splintering, I'm
> worried about the "hidden overhead" everytime a "silent
> splinter" is used.
>
> Let's assume three scenarios (and for now use 2MB pages though
> the same concerns can be extended to 1GB and/or mixed 2MB/1GB):
>
> A) DB code assumes 2MB pages, OS assumes 2MB pages, Xen provides
> only 2MB pages (no splintering occurs)
> B) DB code assumes 2MB pages, OS assumes 2MB pages, Xen provides
> only 4KB pages (because of fragmentation, all 2MB pages have
> been splintered)
> C) DB code assumes 4KB pages, OS assumes 4KB pages, Xen provides
> 4KB pages
>
> Now run some benchmarks. Clearly one would assume that A is
> faster than both B and C. The question is: Is B faster or slower
> than C?
>
> If B is always faster than C, then I have less objection to
> "silent splintering". But if B is sometimes (or maybe always?)
> slower than C, that's a big issue because a user has gone through
> the effort of choosing a better-performing system configuration
> for their software (2MB DB on 2MB OS), but it actually performs
> worse than if they had chosen the "lower performing" configuration.
> And, worse, it will likely degrade across time so performance
> might be fine when the 2MB-DB-on-2MB-OS guest is launched
> but get much worse when it is paused, save/restored, migrated,
> or hot-failed. So even if B is only slightly faster than C,
> if B is much slower than A, this is a problem.
>
> Does that make sense?
>
> Some suggestions:
> 1) If it is possible for an administrator to determine how many
> large pages (both 2MB and 1GB) were requested by each domain
> and how many are currently whole-vs-splintered, that would help.
> 2) We may need some form of memory defragmenter
>
>> -----Original Message-----
>> From: Wei Huang [mailto:wei.huang2@amd.com]
>> Sent: Thursday, March 19, 2009 12:52 PM
>> To: Dan Magenheimer
>> Cc: George Dunlap; xen-devel@lists.xensource.com;
>> keir.fraser@eu.citrix.com; Tim Deegan
>> Subject: Re: [Xen-devel] [RFC][Patches] Xen 1GB Page Table Support
>>
>>
>> Dan,
>>
>> Thanks for your comments. I am not sure about which
>> splintering overhead
>> you are referring to. I can think of three areas:
>>
>> 1. splintering in page allocation
>> In this case, Xen fails to allocate requested page order. So it falls
>> back to smaller pages to setup p2m table. The overhead is
>> O(guest_mem_size), which is a one-time deal.
>>
>> 2. P2M splits large page into smaller pages
>> This is one directional because we don't merge smaller pages to large
>> ones. The worst case is to split all guest large pages. So
>> overhead is
>> O(total_large_page_mem). In long run, the overhead will converge to 0
>> because it is one-directional. Note this overhead also covers
>> when PoD
>> feature is enabled.
>>
>> 3. CPU splintering
>> If CPU does not support 1GB page, it automatically does splintering
>> using smaller ones (such as 2MB). In this case, the overhead
>> is always
>> there. But 1) this only happens to a small number of old chips; 2) I
>> believe that it is still faster than 4K pages. CPUID (1gb feature and
>> 1gb TLB entries) can be used to detect and stop this problem, if we
>> don't really like it.
>>
>> I agree on your concerns. Customers should have the right to
>> make their
>> own decision. But that require new feature is enabled in the first
>> place. For a lot of benchmarks, splintering overhead can be
>> offset with
>> benefits of huge pages. SPECJBB is a good example of using
>> large pages
>> (see Ben Serebrin's presentation in Xen Summit). With that
>> said, I agree
>> with the idea of adding a new option in guest configure file.
>>
>> -Wei
>>
>>
>> Dan Magenheimer wrote:
>>> I'd like to reiterate my argument raised in a previous
>>> discussion of hugepages: Just because this CAN be made
>>> to work, doesn't imply that it SHOULD be made to work.
>>> Real users use larger pages in their OS for the sole
>>> reason that they expect a performance improvement.
>>> If it magically works, but works slow (and possibly
>>> slower than if the OS had just used small pages to
>>> start with), this is likely to lead to unsatisfied
>>> customers, and perhaps allegations such as "Xen sucks
>>> when running databases".
>>>
>>> So, please, let's think this through before implementing
>>> it just because we can. At a minimum, an administrator
>>> should be somehow warned if large pages are getting splintered.
>>>
>>> And if its going in over my objection, please tie it to
>>> a boot option that defaults off so administrator action
>>> is required to allow silent splintering.
>>>
>>> My two cents...
>>> Dan
>>>
>>>> -----Original Message-----
>>>> From: Huang2, Wei [mailto:Wei.Huang2@amd.com]
>>>> Sent: Thursday, March 19, 2009 2:07 AM
>>>> To: George Dunlap
>>>> Cc: xen-devel@lists.xensource.com; keir.fraser@eu.citrix.com;
>>>> Tim Deegan
>>>> Subject: RE: [Xen-devel] [RFC][Patches] Xen 1GB Page Table Support
>>>>
>>>>
>>>> Here are patches using the middle approach. It handles 1GB
>>>> pages in PoD
>>>> by remapping 1GB with 2MB pages & retry. I also added code for 1GB
>>>> detection. Please comment.
>>>>
>>>> Thanks a lot,
>>>>
>>>> -Wei
>>>>
>>>> -----Original Message-----
>>>> From: dunlapg@gmail.com [mailto:dunlapg@gmail.com] On
>> Behalf Of George
>>>> Dunlap
>>>> Sent: Wednesday, March 18, 2009 12:20 PM
>>>> To: Huang2, Wei
>>>> Cc: xen-devel@lists.xensource.com; keir.fraser@eu.citrix.com;
>>>> Tim Deegan
>>>> Subject: Re: [Xen-devel] [RFC][Patches] Xen 1GB Page Table Support
>>>>
>>>> Thanks for doing this work, Wei -- especially all the
>> extra effort for
>>>> the PoD integration.
>>>>
>>>> One question: How well would you say you've tested the PoD
>>>> functionality? Or to put it the other way, how much do I need to
>>>> prioritize testing this before the 3.4 release?
>>>>
>>>> It wouldn't be a bad idea to do as you suggested, and break things
>>>> into 2 meg pages for the PoD case. In order to take the best
>>>> advantage of this in a PoD scenario, you'd need to have a balloon
>>>> driver that could allocate 1G of continuous *guest* p2m
>> space, which
>>>> seems a bit optimistic at this point...
>>>>
>>>> -George
>>>>
>>>> 2009/3/18 Huang2, Wei <Wei.Huang2@amd.com>:
>>>>> Current Xen supports 2MB super pages for NPT/EPT. The
>>>> attached patches
>>>>> extend this feature to support 1GB pages. The PoD
>>>> (populate-on-demand)
>>>>> introduced by George Dunlap made P2M modification harder.
>> I tried to
>>>>> preserve existing PoD design by introducing a 1GB PoD cache list.
>>>>>
>>>>>
>>>>>
>>>>> Note that 1GB PoD can be dropped if we don't care about
>> 1GB when PoD
>>>> is
>>>>> enabled. In this case, we can just split 1GB PDPE into 512x2MB PDE
>>>> entries
>>>>> and grab pages from PoD super list. That can pretty much make
>>>>> 1gb_p2m_pod.patch go away.
>>>>>
>>>>>
>>>>>
>>>>> Any comment/suggestion on design idea will be appreciated.
>>>>>
>>>>>
>>>>>
>>>>> Thanks,
>>>>>
>>>>>
>>>>>
>>>>> -Wei
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> The following is the description:
>>>>>
>>>>> === 1gb_tools.patch ===
>>>>>
>>>>> Extend existing setup_guest() function. Basically, it tries to
>>>> allocate 1GB
>>>>> pages whenever available. If this request fails, it falls
>>>> back to 2MB.
>>>> If
>>>>> both fail, then 4KB pages will be used.
>>>>>
>>>>>
>>>>>
>>>>> === 1gb_p2m.patch ===
>>>>>
>>>>> * p2m_next_level()
>>>>>
>>>>> Check PSE bit of L3 page table entry. If 1GB is found (PSE=1), we
>>>> split 1GB
>>>>> into 512 2MB pages.
>>>>>
>>>>>
>>>>>
>>>>> * p2m_set_entry()
>>>>>
>>>>> Configure the PSE bit of L3 P2M table if page order == 18 (1GB).
>>>>>
>>>>>
>>>>>
>>>>> * p2m_gfn_to_mfn()
>>>>>
>>>>> Add support for 1GB case when doing gfn to mfn
>> translation. When L3
>>>> entry is
>>>>> marked as POPULATE_ON_DEMAND, we call 2m_pod_demand_populate().
>>>> Otherwise,
>>>>> we do the regular address translation (gfn ==> mfn).
>>>>>
>>>>>
>>>>>
>>>>> * p2m_gfn_to_mfn_current()
>>>>>
>>>>> This is similar to p2m_gfn_to_mfn(). When L3 entry s marked as
>>>>> POPULATE_ON_DEMAND, it demands a populate using
>>>> p2m_pod_demand_populate().
>>>>> Otherwise, it does a normal translation. 1GB page is taken into
>>>>> consideration.
>>>>>
>>>>>
>>>>>
>>>>> * set_p2m_entry()
>>>>>
>>>>> Request 1GB page
>>>>>
>>>>>
>>>>>
>>>>> * audit_p2m()
>>>>>
>>>>> Support 1GB while auditing p2m table.
>>>>>
>>>>>
>>>>>
>>>>> * p2m_change_type_global()
>>>>>
>>>>> Deal with 1GB page when changing global page type.
>>>>>
>>>>>
>>>>>
>>>>> === 1gb_p2m_pod.patch ===
>>>>>
>>>>> * xen/include/asm-x86/p2m.h
>>>>>
>>>>> Minor change to deal with PoD. It separates super page
>>>> cache list into
>>>> 2MB
>>>>> and 1GB lists. Similarly, we record last gpfn of sweeping
>>>> for both 2MB
>>>> and
>>>>> 1GB.
>>>>>
>>>>>
>>>>>
>>>>> * p2m_pod_cache_add()
>>>>>
>>>>> Check page order and add 1GB super page into PoD 1GB cache list.
>>>>>
>>>>>
>>>>>
>>>>> * p2m_pod_cache_get()
>>>>>
>>>>> Grab a page from cache list. It tries to break 1GB page
>> into 512 2MB
>>>> pages
>>>>> if 2MB PoD list is empty. Similarly, 4KB can be requested
>> from super
>>>> pages.
>>>>> The breaking order is 2MB then 1GB.
>>>>>
>>>>>
>>>>>
>>>>> * p2m_pod_cache_target()
>>>>>
>>>>> This function is used to set PoD cache size. To increase
>> PoD target,
>>>> we try
>>>>> to allocate 1GB from xen domheap. If this fails, we try
>> 2MB. If both
>>>> fail,
>>>>> we try 4KB which is guaranteed to work.
>>>>>
>>>>>
>>>>>
>>>>> To decrease the target, we use a similar approach. We first try to
>>>> free 1GB
>>>>> pages from 1GB PoD cache list. If such request fails, we
>> try 2MB PoD
>>>> cache
>>>>> list. If both fail, we try 4KB list.
>>>>>
>>>>>
>>>>>
>>>>> * p2m_pod_zero_check_superpage_1gb()
>>>>>
>>>>> This adds a new function to check for 1GB page. This function is
>>>> similar to
>>>>> p2m_pod_zero_check_superpage_2mb().
>>>>>
>>>>>
>>>>>
>>>>> * p2m_pod_zero_check_superpage_1gb()
>>>>>
>>>>> We add a new function to sweep 1GB page from guest memory.
>>>> This is the
>>>> same
>>>>> as p2m_pod_zero_check_superpage_2mb().
>>>>>
>>>>>
>>>>>
>>>>> * p2m_pod_demand_populate()
>>>>>
>>>>> The trick of this function is to do remap_and_retry if
>>>> p2m_pod_cache_get()
>>>>> fails. When p2m_pod_get() fails, this function will
>> splits p2m table
>>>> entry
>>>>> into smaller ones (e.g. 1GB ==> 2MB or 2MB ==> 4KB). That can
>>>> guarantee
>>>>> populate demands always work.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Xen-devel mailing list
>>>>> Xen-devel@lists.xensource.com
>>>>> http://lists.xensource.com/xen-devel
>>>>>
>>>>>
>>
>
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [RFC][Patches] Xen 1GB Page Table Support
2009-03-19 19:56 ` Dan Magenheimer
2009-03-19 21:07 ` Wei Huang
@ 2009-03-20 9:45 ` George Dunlap
2009-03-20 13:40 ` Dan Magenheimer
1 sibling, 1 reply; 23+ messages in thread
From: George Dunlap @ 2009-03-20 9:45 UTC (permalink / raw)
To: Dan Magenheimer
Cc: Tim Deegan, Wei Huang, xen-devel@lists.xensource.com, Keir Fraser
Dan,
Don't forget that this is about the p2m table, which is (if I understand
correctly) orthogonal to what the guest pagetables are doing. So the
scenario, if HAP is used, would be:
A) DB code uses 2MB pages in guest PTs, OS assumes 2MB pages, guest PTs
use 2MB pages, P2M uses 2MB pages
- A tlb miss requires 3 * 3 = 9 reads (Assuming 64-bit guest)
B) DB code uses 2MB pages, OS uses 2MB pages, p2m uses 4K pages
- A tlb miss requires 3 * 4 = 12 reads
C) DB code uses 4k pages, OS uses 4k pages, p2m uses 2MB pages
- A tlb miss requires 4 * 3 = 12 reads
D) DB code uses 4k pages, OS uses 4k pages, p2m uses 4k pages
- A tlb miss requires 4 * 4 = 16 reads
And adding the 1G p2m entries will change the multiplier from 3 to 2
(i.e., 3*2 = 6 reads for superpages, 4*2 = 8 reads for 4k guest pages).
(Those who are more familiar with the hardware, please correct me if
I've made some mistakes or oversimplified things.)
So adding 1G pages to the p2m table shouldn't change expectations of the
guest OS in any case. Using it will benefit the guest to the same
degree whether the guest is using 4k, 2Mb, or 1G pages. (If I understand
correctly.)
-George
Dan Magenheimer wrote:
> Hi Wei --
>
> I'm not worried about the overhead of the splintering, I'm
> worried about the "hidden overhead" everytime a "silent
> splinter" is used.
>
> Let's assume three scenarios (and for now use 2MB pages though
> the same concerns can be extended to 1GB and/or mixed 2MB/1GB):
>
> A) DB code assumes 2MB pages, OS assumes 2MB pages, Xen provides
> only 2MB pages (no splintering occurs)
> B) DB code assumes 2MB pages, OS assumes 2MB pages, Xen provides
> only 4KB pages (because of fragmentation, all 2MB pages have
> been splintered)
> C) DB code assumes 4KB pages, OS assumes 4KB pages, Xen provides
> 4KB pages
>
> Now run some benchmarks. Clearly one would assume that A is
> faster than both B and C. The question is: Is B faster or slower
> than C?
>
> If B is always faster than C, then I have less objection to
> "silent splintering". But if B is sometimes (or maybe always?)
> slower than C, that's a big issue because a user has gone through
> the effort of choosing a better-performing system configuration
> for their software (2MB DB on 2MB OS), but it actually performs
> worse than if they had chosen the "lower performing" configuration.
> And, worse, it will likely degrade across time so performance
> might be fine when the 2MB-DB-on-2MB-OS guest is launched
> but get much worse when it is paused, save/restored, migrated,
> or hot-failed. So even if B is only slightly faster than C,
> if B is much slower than A, this is a problem.
>
> Does that make sense?
>
> Some suggestions:
> 1) If it is possible for an administrator to determine how many
> large pages (both 2MB and 1GB) were requested by each domain
> and how many are currently whole-vs-splintered, that would help.
> 2) We may need some form of memory defragmenter
>
>
>> -----Original Message-----
>> From: Wei Huang [mailto:wei.huang2@amd.com]
>> Sent: Thursday, March 19, 2009 12:52 PM
>> To: Dan Magenheimer
>> Cc: George Dunlap; xen-devel@lists.xensource.com;
>> keir.fraser@eu.citrix.com; Tim Deegan
>> Subject: Re: [Xen-devel] [RFC][Patches] Xen 1GB Page Table Support
>>
>>
>> Dan,
>>
>> Thanks for your comments. I am not sure about which
>> splintering overhead
>> you are referring to. I can think of three areas:
>>
>> 1. splintering in page allocation
>> In this case, Xen fails to allocate requested page order. So it falls
>> back to smaller pages to setup p2m table. The overhead is
>> O(guest_mem_size), which is a one-time deal.
>>
>> 2. P2M splits large page into smaller pages
>> This is one directional because we don't merge smaller pages to large
>> ones. The worst case is to split all guest large pages. So
>> overhead is
>> O(total_large_page_mem). In long run, the overhead will converge to 0
>> because it is one-directional. Note this overhead also covers
>> when PoD
>> feature is enabled.
>>
>> 3. CPU splintering
>> If CPU does not support 1GB page, it automatically does splintering
>> using smaller ones (such as 2MB). In this case, the overhead
>> is always
>> there. But 1) this only happens to a small number of old chips; 2) I
>> believe that it is still faster than 4K pages. CPUID (1gb feature and
>> 1gb TLB entries) can be used to detect and stop this problem, if we
>> don't really like it.
>>
>> I agree on your concerns. Customers should have the right to
>> make their
>> own decision. But that require new feature is enabled in the first
>> place. For a lot of benchmarks, splintering overhead can be
>> offset with
>> benefits of huge pages. SPECJBB is a good example of using
>> large pages
>> (see Ben Serebrin's presentation in Xen Summit). With that
>> said, I agree
>> with the idea of adding a new option in guest configure file.
>>
>> -Wei
>>
>>
>> Dan Magenheimer wrote:
>>
>>> I'd like to reiterate my argument raised in a previous
>>> discussion of hugepages: Just because this CAN be made
>>> to work, doesn't imply that it SHOULD be made to work.
>>> Real users use larger pages in their OS for the sole
>>> reason that they expect a performance improvement.
>>> If it magically works, but works slow (and possibly
>>> slower than if the OS had just used small pages to
>>> start with), this is likely to lead to unsatisfied
>>> customers, and perhaps allegations such as "Xen sucks
>>> when running databases".
>>>
>>> So, please, let's think this through before implementing
>>> it just because we can. At a minimum, an administrator
>>> should be somehow warned if large pages are getting splintered.
>>>
>>> And if its going in over my objection, please tie it to
>>> a boot option that defaults off so administrator action
>>> is required to allow silent splintering.
>>>
>>> My two cents...
>>> Dan
>>>
>>>
>>>> -----Original Message-----
>>>> From: Huang2, Wei [mailto:Wei.Huang2@amd.com]
>>>> Sent: Thursday, March 19, 2009 2:07 AM
>>>> To: George Dunlap
>>>> Cc: xen-devel@lists.xensource.com; keir.fraser@eu.citrix.com;
>>>> Tim Deegan
>>>> Subject: RE: [Xen-devel] [RFC][Patches] Xen 1GB Page Table Support
>>>>
>>>>
>>>> Here are patches using the middle approach. It handles 1GB
>>>> pages in PoD
>>>> by remapping 1GB with 2MB pages & retry. I also added code for 1GB
>>>> detection. Please comment.
>>>>
>>>> Thanks a lot,
>>>>
>>>> -Wei
>>>>
>>>> -----Original Message-----
>>>> From: dunlapg@gmail.com [mailto:dunlapg@gmail.com] On
>>>>
>> Behalf Of George
>>
>>>> Dunlap
>>>> Sent: Wednesday, March 18, 2009 12:20 PM
>>>> To: Huang2, Wei
>>>> Cc: xen-devel@lists.xensource.com; keir.fraser@eu.citrix.com;
>>>> Tim Deegan
>>>> Subject: Re: [Xen-devel] [RFC][Patches] Xen 1GB Page Table Support
>>>>
>>>> Thanks for doing this work, Wei -- especially all the
>>>>
>> extra effort for
>>
>>>> the PoD integration.
>>>>
>>>> One question: How well would you say you've tested the PoD
>>>> functionality? Or to put it the other way, how much do I need to
>>>> prioritize testing this before the 3.4 release?
>>>>
>>>> It wouldn't be a bad idea to do as you suggested, and break things
>>>> into 2 meg pages for the PoD case. In order to take the best
>>>> advantage of this in a PoD scenario, you'd need to have a balloon
>>>> driver that could allocate 1G of continuous *guest* p2m
>>>>
>> space, which
>>
>>>> seems a bit optimistic at this point...
>>>>
>>>> -George
>>>>
>>>> 2009/3/18 Huang2, Wei <Wei.Huang2@amd.com>:
>>>>
>>>>> Current Xen supports 2MB super pages for NPT/EPT. The
>>>>>
>>>> attached patches
>>>>
>>>>> extend this feature to support 1GB pages. The PoD
>>>>>
>>>> (populate-on-demand)
>>>>
>>>>> introduced by George Dunlap made P2M modification harder.
>>>>>
>> I tried to
>>
>>>>> preserve existing PoD design by introducing a 1GB PoD cache list.
>>>>>
>>>>>
>>>>>
>>>>> Note that 1GB PoD can be dropped if we don't care about
>>>>>
>> 1GB when PoD
>>
>>>> is
>>>>
>>>>> enabled. In this case, we can just split 1GB PDPE into 512x2MB PDE
>>>>>
>>>> entries
>>>>
>>>>> and grab pages from PoD super list. That can pretty much make
>>>>> 1gb_p2m_pod.patch go away.
>>>>>
>>>>>
>>>>>
>>>>> Any comment/suggestion on design idea will be appreciated.
>>>>>
>>>>>
>>>>>
>>>>> Thanks,
>>>>>
>>>>>
>>>>>
>>>>> -Wei
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> The following is the description:
>>>>>
>>>>> === 1gb_tools.patch ===
>>>>>
>>>>> Extend existing setup_guest() function. Basically, it tries to
>>>>>
>>>> allocate 1GB
>>>>
>>>>> pages whenever available. If this request fails, it falls
>>>>>
>>>> back to 2MB.
>>>> If
>>>>
>>>>> both fail, then 4KB pages will be used.
>>>>>
>>>>>
>>>>>
>>>>> === 1gb_p2m.patch ===
>>>>>
>>>>> * p2m_next_level()
>>>>>
>>>>> Check PSE bit of L3 page table entry. If 1GB is found (PSE=1), we
>>>>>
>>>> split 1GB
>>>>
>>>>> into 512 2MB pages.
>>>>>
>>>>>
>>>>>
>>>>> * p2m_set_entry()
>>>>>
>>>>> Configure the PSE bit of L3 P2M table if page order == 18 (1GB).
>>>>>
>>>>>
>>>>>
>>>>> * p2m_gfn_to_mfn()
>>>>>
>>>>> Add support for 1GB case when doing gfn to mfn
>>>>>
>> translation. When L3
>>
>>>> entry is
>>>>
>>>>> marked as POPULATE_ON_DEMAND, we call 2m_pod_demand_populate().
>>>>>
>>>> Otherwise,
>>>>
>>>>> we do the regular address translation (gfn ==> mfn).
>>>>>
>>>>>
>>>>>
>>>>> * p2m_gfn_to_mfn_current()
>>>>>
>>>>> This is similar to p2m_gfn_to_mfn(). When L3 entry s marked as
>>>>> POPULATE_ON_DEMAND, it demands a populate using
>>>>>
>>>> p2m_pod_demand_populate().
>>>>
>>>>> Otherwise, it does a normal translation. 1GB page is taken into
>>>>> consideration.
>>>>>
>>>>>
>>>>>
>>>>> * set_p2m_entry()
>>>>>
>>>>> Request 1GB page
>>>>>
>>>>>
>>>>>
>>>>> * audit_p2m()
>>>>>
>>>>> Support 1GB while auditing p2m table.
>>>>>
>>>>>
>>>>>
>>>>> * p2m_change_type_global()
>>>>>
>>>>> Deal with 1GB page when changing global page type.
>>>>>
>>>>>
>>>>>
>>>>> === 1gb_p2m_pod.patch ===
>>>>>
>>>>> * xen/include/asm-x86/p2m.h
>>>>>
>>>>> Minor change to deal with PoD. It separates super page
>>>>>
>>>> cache list into
>>>> 2MB
>>>>
>>>>> and 1GB lists. Similarly, we record last gpfn of sweeping
>>>>>
>>>> for both 2MB
>>>> and
>>>>
>>>>> 1GB.
>>>>>
>>>>>
>>>>>
>>>>> * p2m_pod_cache_add()
>>>>>
>>>>> Check page order and add 1GB super page into PoD 1GB cache list.
>>>>>
>>>>>
>>>>>
>>>>> * p2m_pod_cache_get()
>>>>>
>>>>> Grab a page from cache list. It tries to break 1GB page
>>>>>
>> into 512 2MB
>>
>>>> pages
>>>>
>>>>> if 2MB PoD list is empty. Similarly, 4KB can be requested
>>>>>
>> from super
>>
>>>> pages.
>>>>
>>>>> The breaking order is 2MB then 1GB.
>>>>>
>>>>>
>>>>>
>>>>> * p2m_pod_cache_target()
>>>>>
>>>>> This function is used to set PoD cache size. To increase
>>>>>
>> PoD target,
>>
>>>> we try
>>>>
>>>>> to allocate 1GB from xen domheap. If this fails, we try
>>>>>
>> 2MB. If both
>>
>>>> fail,
>>>>
>>>>> we try 4KB which is guaranteed to work.
>>>>>
>>>>>
>>>>>
>>>>> To decrease the target, we use a similar approach. We first try to
>>>>>
>>>> free 1GB
>>>>
>>>>> pages from 1GB PoD cache list. If such request fails, we
>>>>>
>> try 2MB PoD
>>
>>>> cache
>>>>
>>>>> list. If both fail, we try 4KB list.
>>>>>
>>>>>
>>>>>
>>>>> * p2m_pod_zero_check_superpage_1gb()
>>>>>
>>>>> This adds a new function to check for 1GB page. This function is
>>>>>
>>>> similar to
>>>>
>>>>> p2m_pod_zero_check_superpage_2mb().
>>>>>
>>>>>
>>>>>
>>>>> * p2m_pod_zero_check_superpage_1gb()
>>>>>
>>>>> We add a new function to sweep 1GB page from guest memory.
>>>>>
>>>> This is the
>>>> same
>>>>
>>>>> as p2m_pod_zero_check_superpage_2mb().
>>>>>
>>>>>
>>>>>
>>>>> * p2m_pod_demand_populate()
>>>>>
>>>>> The trick of this function is to do remap_and_retry if
>>>>>
>>>> p2m_pod_cache_get()
>>>>
>>>>> fails. When p2m_pod_get() fails, this function will
>>>>>
>> splits p2m table
>>
>>>> entry
>>>>
>>>>> into smaller ones (e.g. 1GB ==> 2MB or 2MB ==> 4KB). That can
>>>>>
>>>> guarantee
>>>>
>>>>> populate demands always work.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Xen-devel mailing list
>>>>> Xen-devel@lists.xensource.com
>>>>> http://lists.xensource.com/xen-devel
>>>>>
>>>>>
>>>>>
>>
^ permalink raw reply [flat|nested] 23+ messages in thread
* RE: [RFC][Patches] Xen 1GB Page Table Support
2009-03-20 9:45 ` George Dunlap
@ 2009-03-20 13:40 ` Dan Magenheimer
2009-03-20 13:56 ` Wei Huang
2009-03-20 13:59 ` Gianluca Guida
0 siblings, 2 replies; 23+ messages in thread
From: Dan Magenheimer @ 2009-03-20 13:40 UTC (permalink / raw)
To: George Dunlap; +Cc: Tim Deegan, Wei Huang, xen-devel, Keir Fraser
Interesting. And non-intuitive. I think you are saying
that, at least theoretically (and using your ABCD, not
my ABC below), A is always faster than
(B | C), and (B | C) is always faster than D. Taking into
account the fact that the TLB size is fixed (I think),
C will always be faster than B and never slower than D.
So if the theory proves true, that does seem to eliminate
my objection.
Thanks,
Dan
> -----Original Message-----
> From: George Dunlap [mailto:george.dunlap@eu.citrix.com]
> Sent: Friday, March 20, 2009 3:46 AM
> To: Dan Magenheimer
> Cc: Wei Huang; xen-devel@lists.xensource.com; Keir Fraser; Tim Deegan
> Subject: Re: [Xen-devel] [RFC][Patches] Xen 1GB Page Table Support
>
>
> Dan,
>
> Don't forget that this is about the p2m table, which is (if I
> understand
> correctly) orthogonal to what the guest pagetables are doing. So the
> scenario, if HAP is used, would be:
>
> A) DB code uses 2MB pages in guest PTs, OS assumes 2MB pages,
> guest PTs
> use 2MB pages, P2M uses 2MB pages
> - A tlb miss requires 3 * 3 = 9 reads (Assuming 64-bit guest)
> B) DB code uses 2MB pages, OS uses 2MB pages, p2m uses 4K pages
> - A tlb miss requires 3 * 4 = 12 reads
> C) DB code uses 4k pages, OS uses 4k pages, p2m uses 2MB pages
> - A tlb miss requires 4 * 3 = 12 reads
> D) DB code uses 4k pages, OS uses 4k pages, p2m uses 4k pages
> - A tlb miss requires 4 * 4 = 16 reads
>
> And adding the 1G p2m entries will change the multiplier from 3 to 2
> (i.e., 3*2 = 6 reads for superpages, 4*2 = 8 reads for 4k
> guest pages).
>
> (Those who are more familiar with the hardware, please correct me if
> I've made some mistakes or oversimplified things.)
>
> So adding 1G pages to the p2m table shouldn't change
> expectations of the
> guest OS in any case. Using it will benefit the guest to the same
> degree whether the guest is using 4k, 2Mb, or 1G pages. (If I
> understand
> correctly.)
>
> -George
>
> Dan Magenheimer wrote:
> > Hi Wei --
> >
> > I'm not worried about the overhead of the splintering, I'm
> > worried about the "hidden overhead" everytime a "silent
> > splinter" is used.
> >
> > Let's assume three scenarios (and for now use 2MB pages though
> > the same concerns can be extended to 1GB and/or mixed 2MB/1GB):
> >
> > A) DB code assumes 2MB pages, OS assumes 2MB pages, Xen provides
> > only 2MB pages (no splintering occurs)
> > B) DB code assumes 2MB pages, OS assumes 2MB pages, Xen provides
> > only 4KB pages (because of fragmentation, all 2MB pages have
> > been splintered)
> > C) DB code assumes 4KB pages, OS assumes 4KB pages, Xen provides
> > 4KB pages
> >
> > Now run some benchmarks. Clearly one would assume that A is
> > faster than both B and C. The question is: Is B faster or slower
> > than C?
> >
> > If B is always faster than C, then I have less objection to
> > "silent splintering". But if B is sometimes (or maybe always?)
> > slower than C, that's a big issue because a user has gone through
> > the effort of choosing a better-performing system configuration
> > for their software (2MB DB on 2MB OS), but it actually performs
> > worse than if they had chosen the "lower performing" configuration.
> > And, worse, it will likely degrade across time so performance
> > might be fine when the 2MB-DB-on-2MB-OS guest is launched
> > but get much worse when it is paused, save/restored, migrated,
> > or hot-failed. So even if B is only slightly faster than C,
> > if B is much slower than A, this is a problem.
> >
> > Does that make sense?
> >
> > Some suggestions:
> > 1) If it is possible for an administrator to determine how many
> > large pages (both 2MB and 1GB) were requested by each domain
> > and how many are currently whole-vs-splintered, that would help.
> > 2) We may need some form of memory defragmenter
> >
> >
> >> -----Original Message-----
> >> From: Wei Huang [mailto:wei.huang2@amd.com]
> >> Sent: Thursday, March 19, 2009 12:52 PM
> >> To: Dan Magenheimer
> >> Cc: George Dunlap; xen-devel@lists.xensource.com;
> >> keir.fraser@eu.citrix.com; Tim Deegan
> >> Subject: Re: [Xen-devel] [RFC][Patches] Xen 1GB Page Table Support
> >>
> >>
> >> Dan,
> >>
> >> Thanks for your comments. I am not sure about which
> >> splintering overhead
> >> you are referring to. I can think of three areas:
> >>
> >> 1. splintering in page allocation
> >> In this case, Xen fails to allocate requested page order.
> So it falls
> >> back to smaller pages to setup p2m table. The overhead is
> >> O(guest_mem_size), which is a one-time deal.
> >>
> >> 2. P2M splits large page into smaller pages
> >> This is one directional because we don't merge smaller
> pages to large
> >> ones. The worst case is to split all guest large pages. So
> >> overhead is
> >> O(total_large_page_mem). In long run, the overhead will
> converge to 0
> >> because it is one-directional. Note this overhead also covers
> >> when PoD
> >> feature is enabled.
> >>
> >> 3. CPU splintering
> >> If CPU does not support 1GB page, it automatically does
> splintering
> >> using smaller ones (such as 2MB). In this case, the overhead
> >> is always
> >> there. But 1) this only happens to a small number of old
> chips; 2) I
> >> believe that it is still faster than 4K pages. CPUID (1gb
> feature and
> >> 1gb TLB entries) can be used to detect and stop this
> problem, if we
> >> don't really like it.
> >>
> >> I agree on your concerns. Customers should have the right to
> >> make their
> >> own decision. But that require new feature is enabled in the first
> >> place. For a lot of benchmarks, splintering overhead can be
> >> offset with
> >> benefits of huge pages. SPECJBB is a good example of using
> >> large pages
> >> (see Ben Serebrin's presentation in Xen Summit). With that
> >> said, I agree
> >> with the idea of adding a new option in guest configure file.
> >>
> >> -Wei
> >>
> >>
> >> Dan Magenheimer wrote:
> >>
> >>> I'd like to reiterate my argument raised in a previous
> >>> discussion of hugepages: Just because this CAN be made
> >>> to work, doesn't imply that it SHOULD be made to work.
> >>> Real users use larger pages in their OS for the sole
> >>> reason that they expect a performance improvement.
> >>> If it magically works, but works slow (and possibly
> >>> slower than if the OS had just used small pages to
> >>> start with), this is likely to lead to unsatisfied
> >>> customers, and perhaps allegations such as "Xen sucks
> >>> when running databases".
> >>>
> >>> So, please, let's think this through before implementing
> >>> it just because we can. At a minimum, an administrator
> >>> should be somehow warned if large pages are getting splintered.
> >>>
> >>> And if its going in over my objection, please tie it to
> >>> a boot option that defaults off so administrator action
> >>> is required to allow silent splintering.
> >>>
> >>> My two cents...
> >>> Dan
> >>>
> >>>
> >>>> -----Original Message-----
> >>>> From: Huang2, Wei [mailto:Wei.Huang2@amd.com]
> >>>> Sent: Thursday, March 19, 2009 2:07 AM
> >>>> To: George Dunlap
> >>>> Cc: xen-devel@lists.xensource.com; keir.fraser@eu.citrix.com;
> >>>> Tim Deegan
> >>>> Subject: RE: [Xen-devel] [RFC][Patches] Xen 1GB Page
> Table Support
> >>>>
> >>>>
> >>>> Here are patches using the middle approach. It handles 1GB
> >>>> pages in PoD
> >>>> by remapping 1GB with 2MB pages & retry. I also added
> code for 1GB
> >>>> detection. Please comment.
> >>>>
> >>>> Thanks a lot,
> >>>>
> >>>> -Wei
> >>>>
> >>>> -----Original Message-----
> >>>> From: dunlapg@gmail.com [mailto:dunlapg@gmail.com] On
> >>>>
> >> Behalf Of George
> >>
> >>>> Dunlap
> >>>> Sent: Wednesday, March 18, 2009 12:20 PM
> >>>> To: Huang2, Wei
> >>>> Cc: xen-devel@lists.xensource.com; keir.fraser@eu.citrix.com;
> >>>> Tim Deegan
> >>>> Subject: Re: [Xen-devel] [RFC][Patches] Xen 1GB Page
> Table Support
> >>>>
> >>>> Thanks for doing this work, Wei -- especially all the
> >>>>
> >> extra effort for
> >>
> >>>> the PoD integration.
> >>>>
> >>>> One question: How well would you say you've tested the PoD
> >>>> functionality? Or to put it the other way, how much do I need to
> >>>> prioritize testing this before the 3.4 release?
> >>>>
> >>>> It wouldn't be a bad idea to do as you suggested, and
> break things
> >>>> into 2 meg pages for the PoD case. In order to take the best
> >>>> advantage of this in a PoD scenario, you'd need to have a balloon
> >>>> driver that could allocate 1G of continuous *guest* p2m
> >>>>
> >> space, which
> >>
> >>>> seems a bit optimistic at this point...
> >>>>
> >>>> -George
> >>>>
> >>>> 2009/3/18 Huang2, Wei <Wei.Huang2@amd.com>:
> >>>>
> >>>>> Current Xen supports 2MB super pages for NPT/EPT. The
> >>>>>
> >>>> attached patches
> >>>>
> >>>>> extend this feature to support 1GB pages. The PoD
> >>>>>
> >>>> (populate-on-demand)
> >>>>
> >>>>> introduced by George Dunlap made P2M modification harder.
> >>>>>
> >> I tried to
> >>
> >>>>> preserve existing PoD design by introducing a 1GB PoD
> cache list.
> >>>>>
> >>>>>
> >>>>>
> >>>>> Note that 1GB PoD can be dropped if we don't care about
> >>>>>
> >> 1GB when PoD
> >>
> >>>> is
> >>>>
> >>>>> enabled. In this case, we can just split 1GB PDPE into
> 512x2MB PDE
> >>>>>
> >>>> entries
> >>>>
> >>>>> and grab pages from PoD super list. That can pretty much make
> >>>>> 1gb_p2m_pod.patch go away.
> >>>>>
> >>>>>
> >>>>>
> >>>>> Any comment/suggestion on design idea will be appreciated.
> >>>>>
> >>>>>
> >>>>>
> >>>>> Thanks,
> >>>>>
> >>>>>
> >>>>>
> >>>>> -Wei
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>> The following is the description:
> >>>>>
> >>>>> === 1gb_tools.patch ===
> >>>>>
> >>>>> Extend existing setup_guest() function. Basically, it tries to
> >>>>>
> >>>> allocate 1GB
> >>>>
> >>>>> pages whenever available. If this request fails, it falls
> >>>>>
> >>>> back to 2MB.
> >>>> If
> >>>>
> >>>>> both fail, then 4KB pages will be used.
> >>>>>
> >>>>>
> >>>>>
> >>>>> === 1gb_p2m.patch ===
> >>>>>
> >>>>> * p2m_next_level()
> >>>>>
> >>>>> Check PSE bit of L3 page table entry. If 1GB is found
> (PSE=1), we
> >>>>>
> >>>> split 1GB
> >>>>
> >>>>> into 512 2MB pages.
> >>>>>
> >>>>>
> >>>>>
> >>>>> * p2m_set_entry()
> >>>>>
> >>>>> Configure the PSE bit of L3 P2M table if page order == 18 (1GB).
> >>>>>
> >>>>>
> >>>>>
> >>>>> * p2m_gfn_to_mfn()
> >>>>>
> >>>>> Add support for 1GB case when doing gfn to mfn
> >>>>>
> >> translation. When L3
> >>
> >>>> entry is
> >>>>
> >>>>> marked as POPULATE_ON_DEMAND, we call 2m_pod_demand_populate().
> >>>>>
> >>>> Otherwise,
> >>>>
> >>>>> we do the regular address translation (gfn ==> mfn).
> >>>>>
> >>>>>
> >>>>>
> >>>>> * p2m_gfn_to_mfn_current()
> >>>>>
> >>>>> This is similar to p2m_gfn_to_mfn(). When L3 entry s marked as
> >>>>> POPULATE_ON_DEMAND, it demands a populate using
> >>>>>
> >>>> p2m_pod_demand_populate().
> >>>>
> >>>>> Otherwise, it does a normal translation. 1GB page is taken into
> >>>>> consideration.
> >>>>>
> >>>>>
> >>>>>
> >>>>> * set_p2m_entry()
> >>>>>
> >>>>> Request 1GB page
> >>>>>
> >>>>>
> >>>>>
> >>>>> * audit_p2m()
> >>>>>
> >>>>> Support 1GB while auditing p2m table.
> >>>>>
> >>>>>
> >>>>>
> >>>>> * p2m_change_type_global()
> >>>>>
> >>>>> Deal with 1GB page when changing global page type.
> >>>>>
> >>>>>
> >>>>>
> >>>>> === 1gb_p2m_pod.patch ===
> >>>>>
> >>>>> * xen/include/asm-x86/p2m.h
> >>>>>
> >>>>> Minor change to deal with PoD. It separates super page
> >>>>>
> >>>> cache list into
> >>>> 2MB
> >>>>
> >>>>> and 1GB lists. Similarly, we record last gpfn of sweeping
> >>>>>
> >>>> for both 2MB
> >>>> and
> >>>>
> >>>>> 1GB.
> >>>>>
> >>>>>
> >>>>>
> >>>>> * p2m_pod_cache_add()
> >>>>>
> >>>>> Check page order and add 1GB super page into PoD 1GB cache list.
> >>>>>
> >>>>>
> >>>>>
> >>>>> * p2m_pod_cache_get()
> >>>>>
> >>>>> Grab a page from cache list. It tries to break 1GB page
> >>>>>
> >> into 512 2MB
> >>
> >>>> pages
> >>>>
> >>>>> if 2MB PoD list is empty. Similarly, 4KB can be requested
> >>>>>
> >> from super
> >>
> >>>> pages.
> >>>>
> >>>>> The breaking order is 2MB then 1GB.
> >>>>>
> >>>>>
> >>>>>
> >>>>> * p2m_pod_cache_target()
> >>>>>
> >>>>> This function is used to set PoD cache size. To increase
> >>>>>
> >> PoD target,
> >>
> >>>> we try
> >>>>
> >>>>> to allocate 1GB from xen domheap. If this fails, we try
> >>>>>
> >> 2MB. If both
> >>
> >>>> fail,
> >>>>
> >>>>> we try 4KB which is guaranteed to work.
> >>>>>
> >>>>>
> >>>>>
> >>>>> To decrease the target, we use a similar approach. We
> first try to
> >>>>>
> >>>> free 1GB
> >>>>
> >>>>> pages from 1GB PoD cache list. If such request fails, we
> >>>>>
> >> try 2MB PoD
> >>
> >>>> cache
> >>>>
> >>>>> list. If both fail, we try 4KB list.
> >>>>>
> >>>>>
> >>>>>
> >>>>> * p2m_pod_zero_check_superpage_1gb()
> >>>>>
> >>>>> This adds a new function to check for 1GB page. This function is
> >>>>>
> >>>> similar to
> >>>>
> >>>>> p2m_pod_zero_check_superpage_2mb().
> >>>>>
> >>>>>
> >>>>>
> >>>>> * p2m_pod_zero_check_superpage_1gb()
> >>>>>
> >>>>> We add a new function to sweep 1GB page from guest memory.
> >>>>>
> >>>> This is the
> >>>> same
> >>>>
> >>>>> as p2m_pod_zero_check_superpage_2mb().
> >>>>>
> >>>>>
> >>>>>
> >>>>> * p2m_pod_demand_populate()
> >>>>>
> >>>>> The trick of this function is to do remap_and_retry if
> >>>>>
> >>>> p2m_pod_cache_get()
> >>>>
> >>>>> fails. When p2m_pod_get() fails, this function will
> >>>>>
> >> splits p2m table
> >>
> >>>> entry
> >>>>
> >>>>> into smaller ones (e.g. 1GB ==> 2MB or 2MB ==> 4KB). That can
> >>>>>
> >>>> guarantee
> >>>>
> >>>>> populate demands always work.
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>> _______________________________________________
> >>>>> Xen-devel mailing list
> >>>>> Xen-devel@lists.xensource.com
> >>>>> http://lists.xensource.com/xen-devel
> >>>>>
> >>>>>
> >>>>>
> >>
>
>
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [RFC][Patches] Xen 1GB Page Table Support
2009-03-20 13:40 ` Dan Magenheimer
@ 2009-03-20 13:56 ` Wei Huang
2009-03-20 13:59 ` Gianluca Guida
1 sibling, 0 replies; 23+ messages in thread
From: Wei Huang @ 2009-03-20 13:56 UTC (permalink / raw)
To: Dan Magenheimer; +Cc: George Dunlap, Tim Deegan, xen-devel, Keir Fraser
Dan,
I agree on the order: A > C >= B > D. Generally, super page should
perform better than small pages.
In reality, the difference between B & C is subtle. It depends on how
TLB cache is designed and whether TLB flush happens frequently.
-Wei
Dan Magenheimer wrote:
> Interesting. And non-intuitive. I think you are saying
> that, at least theoretically (and using your ABCD, not
> my ABC below), A is always faster than
> (B | C), and (B | C) is always faster than D. Taking into
> account the fact that the TLB size is fixed (I think),
> C will always be faster than B and never slower than D.
>
> So if the theory proves true, that does seem to eliminate
> my objection.
>
> Thanks,
> Dan
>
>> -----Original Message-----
>> From: George Dunlap [mailto:george.dunlap@eu.citrix.com]
>> Sent: Friday, March 20, 2009 3:46 AM
>> To: Dan Magenheimer
>> Cc: Wei Huang; xen-devel@lists.xensource.com; Keir Fraser; Tim Deegan
>> Subject: Re: [Xen-devel] [RFC][Patches] Xen 1GB Page Table Support
>>
>>
>> Dan,
>>
>> Don't forget that this is about the p2m table, which is (if I
>> understand
>> correctly) orthogonal to what the guest pagetables are doing. So the
>> scenario, if HAP is used, would be:
>>
>> A) DB code uses 2MB pages in guest PTs, OS assumes 2MB pages,
>> guest PTs
>> use 2MB pages, P2M uses 2MB pages
>> - A tlb miss requires 3 * 3 = 9 reads (Assuming 64-bit guest)
>> B) DB code uses 2MB pages, OS uses 2MB pages, p2m uses 4K pages
>> - A tlb miss requires 3 * 4 = 12 reads
>> C) DB code uses 4k pages, OS uses 4k pages, p2m uses 2MB pages
>> - A tlb miss requires 4 * 3 = 12 reads
>> D) DB code uses 4k pages, OS uses 4k pages, p2m uses 4k pages
>> - A tlb miss requires 4 * 4 = 16 reads
>>
>> And adding the 1G p2m entries will change the multiplier from 3 to 2
>> (i.e., 3*2 = 6 reads for superpages, 4*2 = 8 reads for 4k
>> guest pages).
>>
>> (Those who are more familiar with the hardware, please correct me if
>> I've made some mistakes or oversimplified things.)
>>
>> So adding 1G pages to the p2m table shouldn't change
>> expectations of the
>> guest OS in any case. Using it will benefit the guest to the same
>> degree whether the guest is using 4k, 2Mb, or 1G pages. (If I
>> understand
>> correctly.)
>>
>> -George
>>
>> Dan Magenheimer wrote:
>>> Hi Wei --
>>>
>>> I'm not worried about the overhead of the splintering, I'm
>>> worried about the "hidden overhead" everytime a "silent
>>> splinter" is used.
>>>
>>> Let's assume three scenarios (and for now use 2MB pages though
>>> the same concerns can be extended to 1GB and/or mixed 2MB/1GB):
>>>
>>> A) DB code assumes 2MB pages, OS assumes 2MB pages, Xen provides
>>> only 2MB pages (no splintering occurs)
>>> B) DB code assumes 2MB pages, OS assumes 2MB pages, Xen provides
>>> only 4KB pages (because of fragmentation, all 2MB pages have
>>> been splintered)
>>> C) DB code assumes 4KB pages, OS assumes 4KB pages, Xen provides
>>> 4KB pages
>>>
>>> Now run some benchmarks. Clearly one would assume that A is
>>> faster than both B and C. The question is: Is B faster or slower
>>> than C?
>>>
>>> If B is always faster than C, then I have less objection to
>>> "silent splintering". But if B is sometimes (or maybe always?)
>>> slower than C, that's a big issue because a user has gone through
>>> the effort of choosing a better-performing system configuration
>>> for their software (2MB DB on 2MB OS), but it actually performs
>>> worse than if they had chosen the "lower performing" configuration.
>>> And, worse, it will likely degrade across time so performance
>>> might be fine when the 2MB-DB-on-2MB-OS guest is launched
>>> but get much worse when it is paused, save/restored, migrated,
>>> or hot-failed. So even if B is only slightly faster than C,
>>> if B is much slower than A, this is a problem.
>>>
>>> Does that make sense?
>>>
>>> Some suggestions:
>>> 1) If it is possible for an administrator to determine how many
>>> large pages (both 2MB and 1GB) were requested by each domain
>>> and how many are currently whole-vs-splintered, that would help.
>>> 2) We may need some form of memory defragmenter
>>>
>>>
>>>> -----Original Message-----
>>>> From: Wei Huang [mailto:wei.huang2@amd.com]
>>>> Sent: Thursday, March 19, 2009 12:52 PM
>>>> To: Dan Magenheimer
>>>> Cc: George Dunlap; xen-devel@lists.xensource.com;
>>>> keir.fraser@eu.citrix.com; Tim Deegan
>>>> Subject: Re: [Xen-devel] [RFC][Patches] Xen 1GB Page Table Support
>>>>
>>>>
>>>> Dan,
>>>>
>>>> Thanks for your comments. I am not sure about which
>>>> splintering overhead
>>>> you are referring to. I can think of three areas:
>>>>
>>>> 1. splintering in page allocation
>>>> In this case, Xen fails to allocate requested page order.
>> So it falls
>>>> back to smaller pages to setup p2m table. The overhead is
>>>> O(guest_mem_size), which is a one-time deal.
>>>>
>>>> 2. P2M splits large page into smaller pages
>>>> This is one directional because we don't merge smaller
>> pages to large
>>>> ones. The worst case is to split all guest large pages. So
>>>> overhead is
>>>> O(total_large_page_mem). In long run, the overhead will
>> converge to 0
>>>> because it is one-directional. Note this overhead also covers
>>>> when PoD
>>>> feature is enabled.
>>>>
>>>> 3. CPU splintering
>>>> If CPU does not support 1GB page, it automatically does
>> splintering
>>>> using smaller ones (such as 2MB). In this case, the overhead
>>>> is always
>>>> there. But 1) this only happens to a small number of old
>> chips; 2) I
>>>> believe that it is still faster than 4K pages. CPUID (1gb
>> feature and
>>>> 1gb TLB entries) can be used to detect and stop this
>> problem, if we
>>>> don't really like it.
>>>>
>>>> I agree on your concerns. Customers should have the right to
>>>> make their
>>>> own decision. But that require new feature is enabled in the first
>>>> place. For a lot of benchmarks, splintering overhead can be
>>>> offset with
>>>> benefits of huge pages. SPECJBB is a good example of using
>>>> large pages
>>>> (see Ben Serebrin's presentation in Xen Summit). With that
>>>> said, I agree
>>>> with the idea of adding a new option in guest configure file.
>>>>
>>>> -Wei
>>>>
>>>>
>>>> Dan Magenheimer wrote:
>>>>
>>>>> I'd like to reiterate my argument raised in a previous
>>>>> discussion of hugepages: Just because this CAN be made
>>>>> to work, doesn't imply that it SHOULD be made to work.
>>>>> Real users use larger pages in their OS for the sole
>>>>> reason that they expect a performance improvement.
>>>>> If it magically works, but works slow (and possibly
>>>>> slower than if the OS had just used small pages to
>>>>> start with), this is likely to lead to unsatisfied
>>>>> customers, and perhaps allegations such as "Xen sucks
>>>>> when running databases".
>>>>>
>>>>> So, please, let's think this through before implementing
>>>>> it just because we can. At a minimum, an administrator
>>>>> should be somehow warned if large pages are getting splintered.
>>>>>
>>>>> And if its going in over my objection, please tie it to
>>>>> a boot option that defaults off so administrator action
>>>>> is required to allow silent splintering.
>>>>>
>>>>> My two cents...
>>>>> Dan
>>>>>
>>>>>
>>>>>> -----Original Message-----
>>>>>> From: Huang2, Wei [mailto:Wei.Huang2@amd.com]
>>>>>> Sent: Thursday, March 19, 2009 2:07 AM
>>>>>> To: George Dunlap
>>>>>> Cc: xen-devel@lists.xensource.com; keir.fraser@eu.citrix.com;
>>>>>> Tim Deegan
>>>>>> Subject: RE: [Xen-devel] [RFC][Patches] Xen 1GB Page
>> Table Support
>>>>>>
>>>>>> Here are patches using the middle approach. It handles 1GB
>>>>>> pages in PoD
>>>>>> by remapping 1GB with 2MB pages & retry. I also added
>> code for 1GB
>>>>>> detection. Please comment.
>>>>>>
>>>>>> Thanks a lot,
>>>>>>
>>>>>> -Wei
>>>>>>
>>>>>> -----Original Message-----
>>>>>> From: dunlapg@gmail.com [mailto:dunlapg@gmail.com] On
>>>>>>
>>>> Behalf Of George
>>>>
>>>>>> Dunlap
>>>>>> Sent: Wednesday, March 18, 2009 12:20 PM
>>>>>> To: Huang2, Wei
>>>>>> Cc: xen-devel@lists.xensource.com; keir.fraser@eu.citrix.com;
>>>>>> Tim Deegan
>>>>>> Subject: Re: [Xen-devel] [RFC][Patches] Xen 1GB Page
>> Table Support
>>>>>> Thanks for doing this work, Wei -- especially all the
>>>>>>
>>>> extra effort for
>>>>
>>>>>> the PoD integration.
>>>>>>
>>>>>> One question: How well would you say you've tested the PoD
>>>>>> functionality? Or to put it the other way, how much do I need to
>>>>>> prioritize testing this before the 3.4 release?
>>>>>>
>>>>>> It wouldn't be a bad idea to do as you suggested, and
>> break things
>>>>>> into 2 meg pages for the PoD case. In order to take the best
>>>>>> advantage of this in a PoD scenario, you'd need to have a balloon
>>>>>> driver that could allocate 1G of continuous *guest* p2m
>>>>>>
>>>> space, which
>>>>
>>>>>> seems a bit optimistic at this point...
>>>>>>
>>>>>> -George
>>>>>>
>>>>>> 2009/3/18 Huang2, Wei <Wei.Huang2@amd.com>:
>>>>>>
>>>>>>> Current Xen supports 2MB super pages for NPT/EPT. The
>>>>>>>
>>>>>> attached patches
>>>>>>
>>>>>>> extend this feature to support 1GB pages. The PoD
>>>>>>>
>>>>>> (populate-on-demand)
>>>>>>
>>>>>>> introduced by George Dunlap made P2M modification harder.
>>>>>>>
>>>> I tried to
>>>>
>>>>>>> preserve existing PoD design by introducing a 1GB PoD
>> cache list.
>>>>>>>
>>>>>>>
>>>>>>> Note that 1GB PoD can be dropped if we don't care about
>>>>>>>
>>>> 1GB when PoD
>>>>
>>>>>> is
>>>>>>
>>>>>>> enabled. In this case, we can just split 1GB PDPE into
>> 512x2MB PDE
>>>>>>>
>>>>>> entries
>>>>>>
>>>>>>> and grab pages from PoD super list. That can pretty much make
>>>>>>> 1gb_p2m_pod.patch go away.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Any comment/suggestion on design idea will be appreciated.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Thanks,
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> -Wei
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> The following is the description:
>>>>>>>
>>>>>>> === 1gb_tools.patch ===
>>>>>>>
>>>>>>> Extend existing setup_guest() function. Basically, it tries to
>>>>>>>
>>>>>> allocate 1GB
>>>>>>
>>>>>>> pages whenever available. If this request fails, it falls
>>>>>>>
>>>>>> back to 2MB.
>>>>>> If
>>>>>>
>>>>>>> both fail, then 4KB pages will be used.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> === 1gb_p2m.patch ===
>>>>>>>
>>>>>>> * p2m_next_level()
>>>>>>>
>>>>>>> Check PSE bit of L3 page table entry. If 1GB is found
>> (PSE=1), we
>>>>>>>
>>>>>> split 1GB
>>>>>>
>>>>>>> into 512 2MB pages.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> * p2m_set_entry()
>>>>>>>
>>>>>>> Configure the PSE bit of L3 P2M table if page order == 18 (1GB).
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> * p2m_gfn_to_mfn()
>>>>>>>
>>>>>>> Add support for 1GB case when doing gfn to mfn
>>>>>>>
>>>> translation. When L3
>>>>
>>>>>> entry is
>>>>>>
>>>>>>> marked as POPULATE_ON_DEMAND, we call 2m_pod_demand_populate().
>>>>>>>
>>>>>> Otherwise,
>>>>>>
>>>>>>> we do the regular address translation (gfn ==> mfn).
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> * p2m_gfn_to_mfn_current()
>>>>>>>
>>>>>>> This is similar to p2m_gfn_to_mfn(). When L3 entry s marked as
>>>>>>> POPULATE_ON_DEMAND, it demands a populate using
>>>>>>>
>>>>>> p2m_pod_demand_populate().
>>>>>>
>>>>>>> Otherwise, it does a normal translation. 1GB page is taken into
>>>>>>> consideration.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> * set_p2m_entry()
>>>>>>>
>>>>>>> Request 1GB page
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> * audit_p2m()
>>>>>>>
>>>>>>> Support 1GB while auditing p2m table.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> * p2m_change_type_global()
>>>>>>>
>>>>>>> Deal with 1GB page when changing global page type.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> === 1gb_p2m_pod.patch ===
>>>>>>>
>>>>>>> * xen/include/asm-x86/p2m.h
>>>>>>>
>>>>>>> Minor change to deal with PoD. It separates super page
>>>>>>>
>>>>>> cache list into
>>>>>> 2MB
>>>>>>
>>>>>>> and 1GB lists. Similarly, we record last gpfn of sweeping
>>>>>>>
>>>>>> for both 2MB
>>>>>> and
>>>>>>
>>>>>>> 1GB.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> * p2m_pod_cache_add()
>>>>>>>
>>>>>>> Check page order and add 1GB super page into PoD 1GB cache list.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> * p2m_pod_cache_get()
>>>>>>>
>>>>>>> Grab a page from cache list. It tries to break 1GB page
>>>>>>>
>>>> into 512 2MB
>>>>
>>>>>> pages
>>>>>>
>>>>>>> if 2MB PoD list is empty. Similarly, 4KB can be requested
>>>>>>>
>>>> from super
>>>>
>>>>>> pages.
>>>>>>
>>>>>>> The breaking order is 2MB then 1GB.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> * p2m_pod_cache_target()
>>>>>>>
>>>>>>> This function is used to set PoD cache size. To increase
>>>>>>>
>>>> PoD target,
>>>>
>>>>>> we try
>>>>>>
>>>>>>> to allocate 1GB from xen domheap. If this fails, we try
>>>>>>>
>>>> 2MB. If both
>>>>
>>>>>> fail,
>>>>>>
>>>>>>> we try 4KB which is guaranteed to work.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> To decrease the target, we use a similar approach. We
>> first try to
>>>>>>>
>>>>>> free 1GB
>>>>>>
>>>>>>> pages from 1GB PoD cache list. If such request fails, we
>>>>>>>
>>>> try 2MB PoD
>>>>
>>>>>> cache
>>>>>>
>>>>>>> list. If both fail, we try 4KB list.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> * p2m_pod_zero_check_superpage_1gb()
>>>>>>>
>>>>>>> This adds a new function to check for 1GB page. This function is
>>>>>>>
>>>>>> similar to
>>>>>>
>>>>>>> p2m_pod_zero_check_superpage_2mb().
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> * p2m_pod_zero_check_superpage_1gb()
>>>>>>>
>>>>>>> We add a new function to sweep 1GB page from guest memory.
>>>>>>>
>>>>>> This is the
>>>>>> same
>>>>>>
>>>>>>> as p2m_pod_zero_check_superpage_2mb().
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> * p2m_pod_demand_populate()
>>>>>>>
>>>>>>> The trick of this function is to do remap_and_retry if
>>>>>>>
>>>>>> p2m_pod_cache_get()
>>>>>>
>>>>>>> fails. When p2m_pod_get() fails, this function will
>>>>>>>
>>>> splits p2m table
>>>>
>>>>>> entry
>>>>>>
>>>>>>> into smaller ones (e.g. 1GB ==> 2MB or 2MB ==> 4KB). That can
>>>>>>>
>>>>>> guarantee
>>>>>>
>>>>>>> populate demands always work.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> Xen-devel mailing list
>>>>>>> Xen-devel@lists.xensource.com
>>>>>>> http://lists.xensource.com/xen-devel
>>>>>>>
>>>>>>>
>>>>>>>
>>>>
>>
>
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [RFC][Patches] Xen 1GB Page Table Support
2009-03-20 13:40 ` Dan Magenheimer
2009-03-20 13:56 ` Wei Huang
@ 2009-03-20 13:59 ` Gianluca Guida
2009-03-20 14:25 ` George Dunlap
1 sibling, 1 reply; 23+ messages in thread
From: Gianluca Guida @ 2009-03-20 13:59 UTC (permalink / raw)
To: Dan Magenheimer
Cc: Gianluca.guida, xen-devel, George Dunlap, Wei Huang, Tim Deegan,
Keir Fraser
On Fri, Mar 20, 2009 at 2:40 PM, Dan Magenheimer
<dan.magenheimer@oracle.com> wrote:
> Interesting. And non-intuitive. I think you are saying
> that, at least theoretically (and using your ABCD, not
> my ABC below), A is always faster than
> (B | C), and (B | C) is always faster than D. Taking into
> account the fact that the TLB size is fixed (I think),
> C will always be faster than B and never slower than D.
Changing the p2m of course won't help in the shadow pagetables case. :/
The 'good' news is that I *think* after recent measures that in
current shadow pagetables a better utilization of the TLB entries
(e.g. setting the PSE bits in the shadows, which is possible after the
2Mb p2m entries) per se doesn't affects performance *at all*.
I will soon have a very small patch that would, if my current analysis
is correct, improve performance in applications using 2Mb pages
without setting PSE in shadows. I'll just need some people helping me
with testing it on these kind of applications.
Thanks,
Gianluca
--
It was a type of people I did not know, I found them very strange and
they did not inspire confidence at all. Later I learned that I had been
introduced to electronic engineers.
E. W. Dijkstra
^ permalink raw reply [flat|nested] 23+ messages in thread* Re: [RFC][Patches] Xen 1GB Page Table Support
2009-03-20 13:59 ` Gianluca Guida
@ 2009-03-20 14:25 ` George Dunlap
2009-03-20 14:21 ` Gianluca Guida
0 siblings, 1 reply; 23+ messages in thread
From: George Dunlap @ 2009-03-20 14:25 UTC (permalink / raw)
To: Gianluca Guida
Cc: Dan Magenheimer, xen-devel@lists.xensource.com, Tim Deegan,
Wei Huang, Gianluca Guida, Keir Fraser
Gianluca Guida wrote:
> Changing the p2m of course won't help in the shadow pagetables case. :/
>
No, but it seems to me that 1G p2m entries can't hurt performance for
shadows either, which is the question Dan was raising.
It might be nice to have some quick "sanity check" benchmarks, just to
make sure that adding the 1G pages won't hurt performance for the normal
case...
-George
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [RFC][Patches] Xen 1GB Page Table Support
2009-03-20 14:25 ` George Dunlap
@ 2009-03-20 14:21 ` Gianluca Guida
2009-03-20 18:16 ` Gianluca Guida
0 siblings, 1 reply; 23+ messages in thread
From: Gianluca Guida @ 2009-03-20 14:21 UTC (permalink / raw)
To: George Dunlap
Cc: Dan Magenheimer, xen-devel@lists.xensource.com, Tim Deegan,
Gianluca Guida, Wei Huang, Keir Fraser
George Dunlap wrote:
> Gianluca Guida wrote:
>> Changing the p2m of course won't help in the shadow pagetables case. :/
>>
> No, but it seems to me that 1G p2m entries can't hurt performance for
> shadows either, which is the question Dan was raising.
Yes, I am sure they won't. They'll make the p2m walk faster, which is
good, but wont' affect shadow performance in a significant way.
> It might be nice to have some quick "sanity check" benchmarks, just to
> make sure that adding the 1G pages won't hurt performance for the normal
> case...
Might do it, but I don't think it's necessary.
Thanks,
Gianluca
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [RFC][Patches] Xen 1GB Page Table Support
2009-03-20 14:21 ` Gianluca Guida
@ 2009-03-20 18:16 ` Gianluca Guida
2009-03-20 18:32 ` Huang2, Wei
0 siblings, 1 reply; 23+ messages in thread
From: Gianluca Guida @ 2009-03-20 18:16 UTC (permalink / raw)
To: George Dunlap
Cc: Dan Magenheimer, xen-devel@lists.xensource.com, Tim Deegan,
Gianluca Guida, Wei Huang, Keir Fraser
Gianluca Guida wrote:
> George Dunlap wrote:
>> It might be nice to have some quick "sanity check" benchmarks, just to
>> make sure that adding the 1G pages won't hurt performance for the normal
>> case...
>
> Might do it, but I don't think it's necessary.
What I meant here is: checking that shadow performance hasn't decreased
shouldn't be necessary. It should be still worth, though, if we'd get
the kind of improvements this patch has on HAP.
Any numbers?
Gianluca
^ permalink raw reply [flat|nested] 23+ messages in thread
* RE: [RFC][Patches] Xen 1GB Page Table Support
2009-03-20 18:16 ` Gianluca Guida
@ 2009-03-20 18:32 ` Huang2, Wei
0 siblings, 0 replies; 23+ messages in thread
From: Huang2, Wei @ 2009-03-20 18:32 UTC (permalink / raw)
To: Gianluca Guida, George Dunlap
Cc: Tim Deegan, Gianluca Guida, Dan Magenheimer, xen-devel,
Keir Fraser
I am working on collecting the numbers. Dan, does Oracle have any
database benchmarks?
-Wei
-----Original Message-----
From: Gianluca Guida [mailto:gianluca.guida@eu.citrix.com]
Sent: Friday, March 20, 2009 1:17 PM
To: George Dunlap
Cc: Gianluca Guida; Dan Magenheimer; Tim Deegan; Huang2, Wei;
xen-devel@lists.xensource.com; Keir Fraser
Subject: Re: [Xen-devel] [RFC][Patches] Xen 1GB Page Table Support
Gianluca Guida wrote:
> George Dunlap wrote:
>> It might be nice to have some quick "sanity check" benchmarks, just
to
>> make sure that adding the 1G pages won't hurt performance for the
normal
>> case...
>
> Might do it, but I don't think it's necessary.
What I meant here is: checking that shadow performance hasn't decreased
shouldn't be necessary. It should be still worth, though, if we'd get
the kind of improvements this patch has on HAP.
Any numbers?
Gianluca
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [RFC][Patches] Xen 1GB Page Table Support
2009-03-19 8:07 ` Huang2, Wei
2009-03-19 14:17 ` Dan Magenheimer
@ 2009-05-19 0:55 ` Keir Fraser
2010-01-13 4:07 ` Xu, Dongxiao
2 siblings, 0 replies; 23+ messages in thread
From: Keir Fraser @ 2009-05-19 0:55 UTC (permalink / raw)
To: Huang2, Wei, George Dunlap; +Cc: Tim Deegan, xen-devel@lists.xensource.com
Now that 3.4 is out, if you want these patches checked in then please
re-send with changeset comments and signed-off-by lines.
Thanks,
Keir
On 19/03/2009 08:07, "Huang2, Wei" <Wei.Huang2@amd.com> wrote:
> Here are patches using the middle approach. It handles 1GB pages in PoD
> by remapping 1GB with 2MB pages & retry. I also added code for 1GB
> detection. Please comment.
>
> Thanks a lot,
>
> -Wei
>
> -----Original Message-----
> From: dunlapg@gmail.com [mailto:dunlapg@gmail.com] On Behalf Of George
> Dunlap
> Sent: Wednesday, March 18, 2009 12:20 PM
> To: Huang2, Wei
> Cc: xen-devel@lists.xensource.com; keir.fraser@eu.citrix.com; Tim Deegan
> Subject: Re: [Xen-devel] [RFC][Patches] Xen 1GB Page Table Support
>
> Thanks for doing this work, Wei -- especially all the extra effort for
> the PoD integration.
>
> One question: How well would you say you've tested the PoD
> functionality? Or to put it the other way, how much do I need to
> prioritize testing this before the 3.4 release?
>
> It wouldn't be a bad idea to do as you suggested, and break things
> into 2 meg pages for the PoD case. In order to take the best
> advantage of this in a PoD scenario, you'd need to have a balloon
> driver that could allocate 1G of continuous *guest* p2m space, which
> seems a bit optimistic at this point...
>
> -George
>
> 2009/3/18 Huang2, Wei <Wei.Huang2@amd.com>:
>> Current Xen supports 2MB super pages for NPT/EPT. The attached patches
>> extend this feature to support 1GB pages. The PoD (populate-on-demand)
>> introduced by George Dunlap made P2M modification harder. I tried to
>> preserve existing PoD design by introducing a 1GB PoD cache list.
>>
>>
>>
>> Note that 1GB PoD can be dropped if we don't care about 1GB when PoD
> is
>> enabled. In this case, we can just split 1GB PDPE into 512x2MB PDE
> entries
>> and grab pages from PoD super list. That can pretty much make
>> 1gb_p2m_pod.patch go away.
>>
>>
>>
>> Any comment/suggestion on design idea will be appreciated.
>>
>>
>>
>> Thanks,
>>
>>
>>
>> -Wei
>>
>>
>>
>>
>>
>> The following is the description:
>>
>> === 1gb_tools.patch ===
>>
>> Extend existing setup_guest() function. Basically, it tries to
> allocate 1GB
>> pages whenever available. If this request fails, it falls back to 2MB.
> If
>> both fail, then 4KB pages will be used.
>>
>>
>>
>> === 1gb_p2m.patch ===
>>
>> * p2m_next_level()
>>
>> Check PSE bit of L3 page table entry. If 1GB is found (PSE=1), we
> split 1GB
>> into 512 2MB pages.
>>
>>
>>
>> * p2m_set_entry()
>>
>> Configure the PSE bit of L3 P2M table if page order == 18 (1GB).
>>
>>
>>
>> * p2m_gfn_to_mfn()
>>
>> Add support for 1GB case when doing gfn to mfn translation. When L3
> entry is
>> marked as POPULATE_ON_DEMAND, we call 2m_pod_demand_populate().
> Otherwise,
>> we do the regular address translation (gfn ==> mfn).
>>
>>
>>
>> * p2m_gfn_to_mfn_current()
>>
>> This is similar to p2m_gfn_to_mfn(). When L3 entry s marked as
>> POPULATE_ON_DEMAND, it demands a populate using
> p2m_pod_demand_populate().
>> Otherwise, it does a normal translation. 1GB page is taken into
>> consideration.
>>
>>
>>
>> * set_p2m_entry()
>>
>> Request 1GB page
>>
>>
>>
>> * audit_p2m()
>>
>> Support 1GB while auditing p2m table.
>>
>>
>>
>> * p2m_change_type_global()
>>
>> Deal with 1GB page when changing global page type.
>>
>>
>>
>> === 1gb_p2m_pod.patch ===
>>
>> * xen/include/asm-x86/p2m.h
>>
>> Minor change to deal with PoD. It separates super page cache list into
> 2MB
>> and 1GB lists. Similarly, we record last gpfn of sweeping for both 2MB
> and
>> 1GB.
>>
>>
>>
>> * p2m_pod_cache_add()
>>
>> Check page order and add 1GB super page into PoD 1GB cache list.
>>
>>
>>
>> * p2m_pod_cache_get()
>>
>> Grab a page from cache list. It tries to break 1GB page into 512 2MB
> pages
>> if 2MB PoD list is empty. Similarly, 4KB can be requested from super
> pages.
>> The breaking order is 2MB then 1GB.
>>
>>
>>
>> * p2m_pod_cache_target()
>>
>> This function is used to set PoD cache size. To increase PoD target,
> we try
>> to allocate 1GB from xen domheap. If this fails, we try 2MB. If both
> fail,
>> we try 4KB which is guaranteed to work.
>>
>>
>>
>> To decrease the target, we use a similar approach. We first try to
> free 1GB
>> pages from 1GB PoD cache list. If such request fails, we try 2MB PoD
> cache
>> list. If both fail, we try 4KB list.
>>
>>
>>
>> * p2m_pod_zero_check_superpage_1gb()
>>
>> This adds a new function to check for 1GB page. This function is
> similar to
>> p2m_pod_zero_check_superpage_2mb().
>>
>>
>>
>> * p2m_pod_zero_check_superpage_1gb()
>>
>> We add a new function to sweep 1GB page from guest memory. This is the
> same
>> as p2m_pod_zero_check_superpage_2mb().
>>
>>
>>
>> * p2m_pod_demand_populate()
>>
>> The trick of this function is to do remap_and_retry if
> p2m_pod_cache_get()
>> fails. When p2m_pod_get() fails, this function will splits p2m table
> entry
>> into smaller ones (e.g. 1GB ==> 2MB or 2MB ==> 4KB). That can
> guarantee
>> populate demands always work.
>>
>>
>>
>>
>>
>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@lists.xensource.com
>> http://lists.xensource.com/xen-devel
>>
>>
>
^ permalink raw reply [flat|nested] 23+ messages in thread
* RE: [RFC][Patches] Xen 1GB Page Table Support
2009-03-19 8:07 ` Huang2, Wei
2009-03-19 14:17 ` Dan Magenheimer
2009-05-19 0:55 ` Keir Fraser
@ 2010-01-13 4:07 ` Xu, Dongxiao
2010-01-13 16:27 ` Wei Huang
2 siblings, 1 reply; 23+ messages in thread
From: Xu, Dongxiao @ 2010-01-13 4:07 UTC (permalink / raw)
To: Huang2, Wei, George Dunlap
Cc: xen-devel@lists.xensource.com, keir.fraser@eu.citrix.com,
Tim Deegan
[-- Attachment #1: Type: text/plain, Size: 5578 bytes --]
Hi, Wei,
I digged out this thread from looooong history...
Do you still have plan to push your 1gb_p2m and 1gb_tool patches into upstream?
I rebased them to fit the latest upstream code (the 1gb_tools.patch is not changed).
Comment on that or any new idea? Thanks!
Best Regards,
-- Dongxiao
Huang2, Wei wrote:
> Here are patches using the middle approach. It handles 1GB pages in
> PoD by remapping 1GB with 2MB pages & retry. I also added code for 1GB
> detection. Please comment.
>
> Thanks a lot,
>
> -Wei
>
> -----Original Message-----
> From: dunlapg@gmail.com [mailto:dunlapg@gmail.com] On Behalf Of George
> Dunlap
> Sent: Wednesday, March 18, 2009 12:20 PM
> To: Huang2, Wei
> Cc: xen-devel@lists.xensource.com; keir.fraser@eu.citrix.com; Tim
> Deegan Subject: Re: [Xen-devel] [RFC][Patches] Xen 1GB Page Table
> Support
>
> Thanks for doing this work, Wei -- especially all the extra effort for
> the PoD integration.
>
> One question: How well would you say you've tested the PoD
> functionality? Or to put it the other way, how much do I need to
> prioritize testing this before the 3.4 release?
>
> It wouldn't be a bad idea to do as you suggested, and break things
> into 2 meg pages for the PoD case. In order to take the best
> advantage of this in a PoD scenario, you'd need to have a balloon
> driver that could allocate 1G of continuous *guest* p2m space, which
> seems a bit optimistic at this point...
>
> -George
>
> 2009/3/18 Huang2, Wei <Wei.Huang2@amd.com>:
>> Current Xen supports 2MB super pages for NPT/EPT. The attached
>> patches extend this feature to support 1GB pages. The PoD
>> (populate-on-demand) introduced by George Dunlap made P2M
>> modification harder. I tried to preserve existing PoD design by
>> introducing a 1GB PoD cache list.
>>
>>
>>
>> Note that 1GB PoD can be dropped if we don't care about 1GB when PoD
>> is enabled. In this case, we can just split 1GB PDPE into 512x2MB
>> PDE entries and grab pages from PoD super list. That can pretty much
>> make 1gb_p2m_pod.patch go away.
>>
>>
>>
>> Any comment/suggestion on design idea will be appreciated.
>>
>>
>>
>> Thanks,
>>
>>
>>
>> -Wei
>>
>>
>>
>>
>>
>> The following is the description:
>>
>> === 1gb_tools.patch ===
>>
>> Extend existing setup_guest() function. Basically, it tries to
>> allocate 1GB pages whenever available. If this request fails, it
>> falls back to 2MB. If both fail, then 4KB pages will be used.
>>
>>
>>
>> === 1gb_p2m.patch ===
>>
>> * p2m_next_level()
>>
>> Check PSE bit of L3 page table entry. If 1GB is found (PSE=1), we
>> split 1GB into 512 2MB pages.
>>
>>
>>
>> * p2m_set_entry()
>>
>> Configure the PSE bit of L3 P2M table if page order == 18 (1GB).
>>
>>
>>
>> * p2m_gfn_to_mfn()
>>
>> Add support for 1GB case when doing gfn to mfn translation. When L3
>> entry is marked as POPULATE_ON_DEMAND, we call
>> 2m_pod_demand_populate(). Otherwise, we do the regular address
>> translation (gfn ==> mfn).
>>
>>
>>
>> * p2m_gfn_to_mfn_current()
>>
>> This is similar to p2m_gfn_to_mfn(). When L3 entry s marked as
>> POPULATE_ON_DEMAND, it demands a populate using
>> p2m_pod_demand_populate(). Otherwise, it does a normal translation.
>> 1GB page is taken into consideration.
>>
>>
>>
>> * set_p2m_entry()
>>
>> Request 1GB page
>>
>>
>>
>> * audit_p2m()
>>
>> Support 1GB while auditing p2m table.
>>
>>
>>
>> * p2m_change_type_global()
>>
>> Deal with 1GB page when changing global page type.
>>
>>
>>
>> === 1gb_p2m_pod.patch ===
>>
>> * xen/include/asm-x86/p2m.h
>>
>> Minor change to deal with PoD. It separates super page cache list
>> into 2MB and 1GB lists. Similarly, we record last gpfn of sweeping
>> for both 2MB and 1GB.
>>
>>
>>
>> * p2m_pod_cache_add()
>>
>> Check page order and add 1GB super page into PoD 1GB cache list.
>>
>>
>>
>> * p2m_pod_cache_get()
>>
>> Grab a page from cache list. It tries to break 1GB page into 512 2MB
>> pages if 2MB PoD list is empty. Similarly, 4KB can be requested from
>> super pages. The breaking order is 2MB then 1GB.
>>
>>
>>
>> * p2m_pod_cache_target()
>>
>> This function is used to set PoD cache size. To increase PoD target,
>> we try to allocate 1GB from xen domheap. If this fails, we try 2MB.
>> If both fail, we try 4KB which is guaranteed to work.
>>
>>
>>
>> To decrease the target, we use a similar approach. We first try to
>> free 1GB pages from 1GB PoD cache list. If such request fails, we
>> try 2MB PoD cache list. If both fail, we try 4KB list.
>>
>>
>>
>> * p2m_pod_zero_check_superpage_1gb()
>>
>> This adds a new function to check for 1GB page. This function is
>> similar to p2m_pod_zero_check_superpage_2mb().
>>
>>
>>
>> * p2m_pod_zero_check_superpage_1gb()
>>
>> We add a new function to sweep 1GB page from guest memory. This is
>> the same as p2m_pod_zero_check_superpage_2mb().
>>
>>
>>
>> * p2m_pod_demand_populate()
>>
>> The trick of this function is to do remap_and_retry if
>> p2m_pod_cache_get() fails. When p2m_pod_get() fails, this function
>> will splits p2m table entry into smaller ones (e.g. 1GB ==> 2MB or
>> 2MB ==> 4KB). That can guarantee populate demands always work.
>>
>>
>>
>>
>>
>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@lists.xensource.com
>> http://lists.xensource.com/xen-devel
[-- Attachment #2: 1gb_tools.patch --]
[-- Type: application/octet-stream, Size: 7472 bytes --]
# HG changeset patch
# User root@weisles1064.amd.com
# Date 1236740196 18000
# Node ID 05aeb649fdab9e8cc3bc541dc3a014658a85611f
# Parent fe4b23bd3a954a640c922202249688eb1b981ce0
1GB nested paging support: tools
diff -r fe4b23bd3a95 -r 05aeb649fdab tools/libxc/xc_hvm_build.c
--- a/tools/libxc/xc_hvm_build.c Wed Mar 18 13:25:25 2009 +0000
+++ b/tools/libxc/xc_hvm_build.c Tue Mar 10 21:56:36 2009 -0500
@@ -19,8 +19,10 @@
#include <xen/libelf/libelf.h>
-#define SUPERPAGE_PFN_SHIFT 9
-#define SUPERPAGE_NR_PFNS (1UL << SUPERPAGE_PFN_SHIFT)
+#define SUPERPAGE_2MB_SHIFT 9
+#define SUPERPAGE_2MB_NR_PFNS (1UL << SUPERPAGE_2MB_SHIFT)
+#define SUPERPAGE_1GB_SHIFT 18
+#define SUPERPAGE_1GB_NR_PFNS (1UL << SUPERPAGE_1GB_SHIFT)
#define SPECIALPAGE_BUFIOREQ 0
#define SPECIALPAGE_XENSTORE 1
@@ -117,6 +119,8 @@ static int setup_guest(int xc_handle,
uint64_t v_start, v_end;
int rc;
xen_capabilities_info_t caps;
+ unsigned long stat_normal_pages = 0, stat_2mb_pages = 0,
+ stat_1gb_pages = 0;
int pod_mode = 0;
@@ -166,35 +170,43 @@ static int setup_guest(int xc_handle,
/*
* Allocate memory for HVM guest, skipping VGA hole 0xA0000-0xC0000.
- * We allocate pages in batches of no more than 8MB to ensure that
- * we can be preempted and hence dom0 remains responsive.
+ *
+ * We attempt to allocate 1GB pages if possible. It falls back on 2MB
+ * pages if 1GB allocation fails. 4KB pages will be used eventually if
+ * both fail.
+ *
+ * Under 2MB mode, we allocate pages in batches of no more than 8MB to
+ * ensure that we can be preempted and hence dom0 remains responsive.
*/
rc = xc_domain_memory_populate_physmap(
xc_handle, dom, 0xa0, 0, 0, &page_array[0x00]);
cur_pages = 0xc0;
+ stat_normal_pages = 0xc0;
while ( (rc == 0) && (nr_pages > cur_pages) )
{
/* Clip count to maximum 8MB extent. */
unsigned long count = nr_pages - cur_pages;
- if ( count > 2048 )
- count = 2048;
-
- /* Clip partial superpage extents to superpage boundaries. */
- if ( ((cur_pages & (SUPERPAGE_NR_PFNS-1)) != 0) &&
- (count > (-cur_pages & (SUPERPAGE_NR_PFNS-1))) )
- count = -cur_pages & (SUPERPAGE_NR_PFNS-1); /* clip s.p. tail */
- else if ( ((count & (SUPERPAGE_NR_PFNS-1)) != 0) &&
- (count > SUPERPAGE_NR_PFNS) )
- count &= ~(SUPERPAGE_NR_PFNS - 1); /* clip non-s.p. tail */
-
- /* Attempt to allocate superpage extents. */
- if ( ((count | cur_pages) & (SUPERPAGE_NR_PFNS - 1)) == 0 )
+ unsigned long max_pages = SUPERPAGE_1GB_NR_PFNS;
+
+ if ( count > max_pages )
+ count = max_pages;
+
+ /* Take care the corner cases of super page tails */
+ if ( ((cur_pages & (SUPERPAGE_1GB_NR_PFNS-1)) != 0) &&
+ (count > (-cur_pages & (SUPERPAGE_1GB_NR_PFNS-1))) )
+ count = -cur_pages & (SUPERPAGE_1GB_NR_PFNS-1);
+ else if ( ((count & (SUPERPAGE_1GB_NR_PFNS-1)) != 0) &&
+ (count > SUPERPAGE_1GB_NR_PFNS) )
+ count &= ~(SUPERPAGE_1GB_NR_PFNS - 1);
+
+ /* Attemp to allocate 1GB super page */
+ if ( ((count | cur_pages) & (SUPERPAGE_1GB_NR_PFNS - 1)) == 0 )
{
long done;
- xen_pfn_t sp_extents[count >> SUPERPAGE_PFN_SHIFT];
+ xen_pfn_t sp_extents[count >> SUPERPAGE_1GB_SHIFT];
struct xen_memory_reservation sp_req = {
- .nr_extents = count >> SUPERPAGE_PFN_SHIFT,
- .extent_order = SUPERPAGE_PFN_SHIFT,
+ .nr_extents = count >> SUPERPAGE_1GB_SHIFT,
+ .extent_order = SUPERPAGE_1GB_SHIFT,
.domid = dom
};
@@ -203,11 +215,12 @@ static int setup_guest(int xc_handle,
set_xen_guest_handle(sp_req.extent_start, sp_extents);
for ( i = 0; i < sp_req.nr_extents; i++ )
- sp_extents[i] = page_array[cur_pages+(i<<SUPERPAGE_PFN_SHIFT)];
+ sp_extents[i] = page_array[cur_pages+(i<<SUPERPAGE_1GB_SHIFT)];
done = xc_memory_op(xc_handle, XENMEM_populate_physmap, &sp_req);
if ( done > 0 )
{
- done <<= SUPERPAGE_PFN_SHIFT;
+ stat_1gb_pages += done;
+ done <<= SUPERPAGE_1GB_SHIFT;
if ( pod_mode && target_pages > cur_pages )
{
int d = target_pages - cur_pages;
@@ -218,12 +231,60 @@ static int setup_guest(int xc_handle,
}
}
+ if ( count != 0 )
+ {
+ max_pages = 2048;
+ if ( count > max_pages )
+ count = max_pages;
+
+ /* Clip partial superpage extents to superpage boundaries. */
+ if ( ((cur_pages & (SUPERPAGE_2MB_NR_PFNS-1)) != 0) &&
+ (count > (-cur_pages & (SUPERPAGE_2MB_NR_PFNS-1))) )
+ count = -cur_pages & (SUPERPAGE_2MB_NR_PFNS-1);
+ else if ( ((count & (SUPERPAGE_2MB_NR_PFNS-1)) != 0) &&
+ (count > SUPERPAGE_2MB_NR_PFNS) )
+ count &= ~(SUPERPAGE_2MB_NR_PFNS - 1); /* clip non-s.p. tail */
+
+ /* Attempt to allocate superpage extents. */
+ if ( ((count | cur_pages) & (SUPERPAGE_2MB_NR_PFNS - 1)) == 0 )
+ {
+ long done;
+ xen_pfn_t sp_extents[count >> SUPERPAGE_2MB_SHIFT];
+ struct xen_memory_reservation sp_req = {
+ .nr_extents = count >> SUPERPAGE_2MB_SHIFT,
+ .extent_order = SUPERPAGE_2MB_SHIFT,
+ .domid = dom
+ };
+
+ if ( pod_mode )
+ sp_req.mem_flags = XENMEMF_populate_on_demand;
+
+ set_xen_guest_handle(sp_req.extent_start, sp_extents);
+ for ( i = 0; i < sp_req.nr_extents; i++ )
+ sp_extents[i] = page_array[cur_pages+(i<<SUPERPAGE_2MB_SHIFT)];
+ done = xc_memory_op(xc_handle, XENMEM_populate_physmap, &sp_req);
+ if ( done > 0 )
+ {
+ stat_2mb_pages += done;
+ done <<= SUPERPAGE_2MB_SHIFT;
+ if ( pod_mode && target_pages > cur_pages )
+ {
+ int d = target_pages - cur_pages;
+ pod_pages += ( done < d ) ? done : d;
+ }
+ cur_pages += done;
+ count -= done;
+ }
+ }
+ }
+
/* Fall back to 4kB extents. */
if ( count != 0 )
{
rc = xc_domain_memory_populate_physmap(
xc_handle, dom, count, 0, 0, &page_array[cur_pages]);
cur_pages += count;
+ stat_normal_pages += count;
if ( pod_mode )
pod_pages -= count;
}
@@ -241,6 +302,12 @@ static int setup_guest(int xc_handle,
goto error_out;
}
+ IPRINTF("PHYSICAL MEMORY ALLOCATION:\n"
+ " 4KB PAGES: 0x%016lx\n"
+ " 2MB PAGES: 0x%016lx\n"
+ " 1GB PAGES: 0x%016lx\n",
+ stat_normal_pages, stat_2mb_pages, stat_1gb_pages);
+
if ( loadelfimage(&elf, xc_handle, dom, page_array) != 0 )
goto error_out;
[-- Attachment #3: 1gb_p2m_rebase.patch --]
[-- Type: application/octet-stream, Size: 12099 bytes --]
diff -r 683bf4ce2e93 xen/arch/x86/mm/p2m.c
--- a/xen/arch/x86/mm/p2m.c Mon Jan 04 10:35:16 2010 +0000
+++ b/xen/arch/x86/mm/p2m.c Thu Jan 07 23:56:36 2010 +0800
@@ -187,7 +187,36 @@ p2m_next_level(struct domain *d, mfn_t *
ASSERT(l1e_get_flags(*p2m_entry) & (_PAGE_PRESENT|_PAGE_PSE));
- /* split single large page into 4KB page in P2M table */
+ /* split 1GB pages into 2MB pages */
+ if ( type == PGT_l2_page_table && (l1e_get_flags(*p2m_entry) & _PAGE_PSE) )
+ {
+ unsigned long flags, pfn;
+ struct page_info *pg = d->arch.p2m->alloc_page(d);
+ if ( pg == NULL )
+ return 0;
+ page_list_add_tail(pg, &d->arch.p2m->pages);
+ pg->u.inuse.type_info = PGT_l1_page_table | 1 | PGT_validated;
+ pg->count_info = 1;
+
+ flags = l1e_get_flags(*p2m_entry);
+ pfn = l1e_get_pfn(*p2m_entry);
+
+ l1_entry = map_domain_page(mfn_x(page_to_mfn(pg)));
+ for ( i = 0; i < L2_PAGETABLE_ENTRIES; i++ )
+ {
+ new_entry = l1e_from_pfn(pfn + (i * L1_PAGETABLE_ENTRIES), flags);
+ paging_write_p2m_entry(d, gfn, l1_entry+i, *table_mfn, new_entry,
+ 2);
+ }
+ unmap_domain_page(l1_entry);
+ new_entry = l1e_from_pfn(mfn_x(page_to_mfn(pg)),
+ __PAGE_HYPERVISOR|_PAGE_USER); //disable PSE
+ paging_write_p2m_entry(d, gfn,
+ p2m_entry, *table_mfn, new_entry, 3);
+ }
+
+
+ /* split single 2MB large page into 4KB page in P2M table */
if ( type == PGT_l1_page_table && (l1e_get_flags(*p2m_entry) & _PAGE_PSE) )
{
unsigned long flags, pfn;
@@ -1034,6 +1063,19 @@ p2m_pod_demand_populate(struct domain *d
if ( unlikely(d->is_dying) )
goto out_fail;
+ /* Because PoD does not have cache list for 1GB pages, it has to remap
+ * 1GB region to 2MB chunks for a retry. */
+ if ( order == 18 )
+ {
+ gfn_aligned = (gfn >> order) << order;
+ for( i = 0; i < (1 << order); i += (1 << 9) )
+ set_p2m_entry(d, gfn_aligned + i, _mfn(POPULATE_ON_DEMAND_MFN), 9,
+ p2m_populate_on_demand);
+ audit_p2m(d);
+ p2m_unlock(p2md);
+ return 0;
+ }
+
/* If we're low, start a sweep */
if ( order == 9 && page_list_empty(&p2md->pod.super) )
p2m_pod_emergency_sweep_super(d);
@@ -1139,6 +1181,7 @@ p2m_set_entry(struct domain *d, unsigned
l1_pgentry_t *p2m_entry;
l1_pgentry_t entry_content;
l2_pgentry_t l2e_content;
+ l3_pgentry_t l3e_content;
int rv=0;
#if CONFIG_PAGING_LEVELS >= 4
@@ -1148,18 +1191,44 @@ p2m_set_entry(struct domain *d, unsigned
goto out;
#endif
/*
+ * Try to allocate 1GB page table if this feature is supported.
+ *
* When using PAE Xen, we only allow 33 bits of pseudo-physical
* address in translated guests (i.e. 8 GBytes). This restriction
* comes from wanting to map the P2M table into the 16MB RO_MPT hole
* in Xen's address space for translated PV guests.
* When using AMD's NPT on PAE Xen, we are restricted to 4GB.
*/
- if ( !p2m_next_level(d, &table_mfn, &table, &gfn_remainder, gfn,
- L3_PAGETABLE_SHIFT - PAGE_SHIFT,
- ((CONFIG_PAGING_LEVELS == 3)
- ? (d->arch.hvm_domain.hap_enabled ? 4 : 8)
- : L3_PAGETABLE_ENTRIES),
- PGT_l2_page_table) )
+ if ( page_order == 18 )
+ {
+ p2m_entry = p2m_find_entry(table, &gfn_remainder, gfn,
+ L3_PAGETABLE_SHIFT - PAGE_SHIFT,
+ L3_PAGETABLE_ENTRIES);
+ ASSERT(p2m_entry);
+ if ( (l1e_get_flags(*p2m_entry) & _PAGE_PRESENT) &&
+ !(l1e_get_flags(*p2m_entry) & _PAGE_PSE) )
+ {
+ P2M_ERROR("configure P2M table L3 entry with large page\n");
+ domain_crash(d);
+ goto out;
+ }
+
+ if ( mfn_valid(mfn) )
+ l3e_content = l3e_from_pfn(mfn_x(mfn),
+ __PAGE_HYPERVISOR|_PAGE_USER|_PAGE_PSE);
+ else
+ l3e_content = l3e_empty();
+
+ entry_content.l1 = l3e_content.l3;
+ paging_write_p2m_entry(d, gfn, p2m_entry, table_mfn, entry_content, 3);
+
+ }
+ else if ( !p2m_next_level(d, &table_mfn, &table, &gfn_remainder, gfn,
+ L3_PAGETABLE_SHIFT - PAGE_SHIFT,
+ ((CONFIG_PAGING_LEVELS == 3)
+ ? (d->arch.hvm_domain.hap_enabled ? 4 : 8)
+ : L3_PAGETABLE_ENTRIES),
+ PGT_l2_page_table) )
goto out;
if ( page_order == 0 )
@@ -1181,7 +1250,7 @@ p2m_set_entry(struct domain *d, unsigned
/* level 1 entry */
paging_write_p2m_entry(d, gfn, p2m_entry, table_mfn, entry_content, 1);
}
- else
+ else if ( page_order == 9 )
{
p2m_entry = p2m_find_entry(table, &gfn_remainder, gfn,
L2_PAGETABLE_SHIFT - PAGE_SHIFT,
@@ -1278,11 +1347,31 @@ p2m_gfn_to_mfn(struct domain *d, unsigne
#else
l3e += l3_table_offset(addr);
#endif
+pod_retry_l3:
if ( (l3e_get_flags(*l3e) & _PAGE_PRESENT) == 0 )
{
+ if ( p2m_flags_to_type(l3e_get_flags(*l3e)) == p2m_populate_on_demand )
+ {
+ if ( q != p2m_query )
+ {
+ if ( !p2m_pod_demand_populate(d, gfn, 18, q) )
+ goto pod_retry_l3;
+ }
+ else
+ *t = p2m_populate_on_demand;
+ }
unmap_domain_page(l3e);
return _mfn(INVALID_MFN);
}
+ else if ( (l3e_get_flags(*l3e) & _PAGE_PSE) )
+ {
+ mfn = _mfn(l3e_get_pfn(*l3e) +
+ l2_table_offset(addr) * L1_PAGETABLE_ENTRIES +
+ l1_table_offset(addr));
+ unmap_domain_page(l3e);
+ return mfn_valid(mfn) ? mfn : _mfn(INVALID_MFN);
+ }
+
mfn = _mfn(l3e_get_pfn(*l3e));
unmap_domain_page(l3e);
}
@@ -1363,10 +1452,57 @@ static mfn_t p2m_gfn_to_mfn_current(unsi
{
l1_pgentry_t l1e = l1e_empty(), *p2m_entry;
l2_pgentry_t l2e = l2e_empty();
+ l3_pgentry_t l3e = l3e_empty();
int ret;
ASSERT(gfn < (RO_MPT_VIRT_END - RO_MPT_VIRT_START)
/ sizeof(l1_pgentry_t));
+
+ /*
+ * Read & process L3
+ */
+ p2m_entry = (l1_pgentry_t *)
+ &__linear_l2_table[l2_linear_offset(RO_MPT_VIRT_START)
+ + l3_linear_offset(addr)];
+ pod_retry_l3:
+ ret = __copy_from_user(&l3e, p2m_entry, sizeof(l3e));
+
+ if ( ret != 0 || !(l3e_get_flags(l3e) & _PAGE_PRESENT) )
+ {
+ if ( (l3e_get_flags(l3e) & _PAGE_PSE) &&
+ (p2m_flags_to_type(l3e_get_flags(l3e)) == p2m_populate_on_demand) )
+ {
+ /* The read has succeeded, so we know that mapping exists */
+ if ( q != p2m_query )
+ {
+ if ( !p2m_pod_demand_populate(current->domain, gfn, 18, q) )
+ goto pod_retry_l3;
+ p2mt = p2m_invalid;
+ printk("%s: Allocate 1GB failed!\n", __func__);
+ goto out;
+ }
+ else
+ {
+ p2mt = p2m_populate_on_demand;
+ goto out;
+ }
+ }
+ goto pod_retry_l2;
+ }
+
+ if ( l3e_get_flags(l3e) & _PAGE_PSE )
+ {
+ p2mt = p2m_flags_to_type(l3e_get_flags(l3e));
+ ASSERT(l3e_get_pfn(l3e) != INVALID_MFN || !p2m_is_ram(p2mt));
+ if (p2m_is_valid(p2mt) )
+ mfn = _mfn(l3e_get_pfn(l3e) +
+ l2_table_offset(addr) * L1_PAGETABLE_ENTRIES +
+ l1_table_offset(addr));
+ else
+ p2mt = p2m_mmio_dm;
+
+ goto out;
+ }
/*
* Read & process L2
@@ -1522,8 +1658,10 @@ int set_p2m_entry(struct domain *d, unsi
while ( todo )
{
if ( is_hvm_domain(d) && d->arch.hvm_domain.hap_enabled )
- order = (((gfn | mfn_x(mfn) | todo) & (SUPERPAGE_PAGES - 1)) == 0) ?
- 9 : 0;
+ order = ( (((gfn | mfn_x(mfn) | todo) & ((1ul << 18) - 1)) == 0) ) ?
+ 18 :
+ (((gfn | mfn_x(mfn) | todo) & ((1ul << 9) - 1)) == 0) ? 9 : 0;
+
else
order = 0;
if ( !d->arch.p2m->set_entry(d, gfn, mfn, order, p2mt) )
@@ -1793,6 +1931,31 @@ static void audit_p2m(struct domain *d)
gfn += 1 << (L3_PAGETABLE_SHIFT - PAGE_SHIFT);
continue;
}
+
+ /* check for 1GB super page */
+ if ( l3e_get_flags(l3e[i3]) & _PAGE_PSE )
+ {
+ mfn = l3e_get_pfn(l3e[i3]);
+ ASSERT(mfn_valid(_mfn(mfn)));
+ /* we have to cover 512x512 4K pages */
+ for ( i2 = 0;
+ i2 < (L2_PAGETABLE_ENTRIES * L1_PAGETABLE_ENTRIES);
+ i2++)
+ {
+ m2pfn = get_gpfn_from_mfn(mfn+i2);
+ if ( m2pfn != (gfn + i2) )
+ {
+ pmbad++;
+ P2M_PRINTK("mismatch: gfn %#lx -> mfn %#lx"
+ " -> gfn %#lx\n", gfn+i2, mfn+i2,
+ m2pfn);
+ BUG();
+ }
+ gfn += 1 << (L3_PAGETABLE_SHIFT - PAGE_SHIFT);
+ continue;
+ }
+ }
+
l2e = map_domain_page(mfn_x(_mfn(l3e_get_pfn(l3e[i3]))));
for ( i2 = 0; i2 < L2_PAGETABLE_ENTRIES; i2++ )
{
@@ -2150,7 +2313,7 @@ void p2m_change_type_global(struct domai
l1_pgentry_t l1e_content;
l1_pgentry_t *l1e;
l2_pgentry_t *l2e;
- mfn_t l1mfn, l2mfn;
+ mfn_t l1mfn, l2mfn, l3mfn;
unsigned long i1, i2, i3;
l3_pgentry_t *l3e;
#if CONFIG_PAGING_LEVELS == 4
@@ -2171,6 +2334,7 @@ void p2m_change_type_global(struct domai
#if CONFIG_PAGING_LEVELS == 4
l4e = map_domain_page(mfn_x(pagetable_get_mfn(d->arch.phys_table)));
#else /* CONFIG_PAGING_LEVELS == 3 */
+ l3mfn = _mfn(mfn_x(pagetable_get_mfn(d->arch.phys_table)));
l3e = map_domain_page(mfn_x(pagetable_get_mfn(d->arch.phys_table)));
#endif
@@ -2181,6 +2345,7 @@ void p2m_change_type_global(struct domai
{
continue;
}
+ l3mfn = _mfn(l4e_get_pfn(l4e[i4]));
l3e = map_domain_page(l4e_get_pfn(l4e[i4]));
#endif
for ( i3 = 0;
@@ -2191,6 +2356,20 @@ void p2m_change_type_global(struct domai
{
continue;
}
+ if ( (l3e_get_flags(l3e[i3]) & _PAGE_PSE) )
+ {
+ flags = l3e_get_flags(l3e[i3]);
+ if ( p2m_flags_to_type(flags) != ot )
+ continue;
+ mfn = l3e_get_pfn(l3e[i3]);
+ gfn = get_gpfn_from_mfn(mfn);
+ flags = p2m_type_to_flags(nt);
+ l1e_content = l1e_from_pfn(mfn, flags | _PAGE_PSE);
+ paging_write_p2m_entry(d, gfn, (l1_pgentry_t *)&l3e[i3],
+ l3mfn, l1e_content, 3);
+ continue;
+ }
+
l2mfn = _mfn(l3e_get_pfn(l3e[i3]));
l2e = map_domain_page(l3e_get_pfn(l3e[i3]));
for ( i2 = 0; i2 < L2_PAGETABLE_ENTRIES; i2++ )
[-- Attachment #4: Type: text/plain, Size: 138 bytes --]
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
^ permalink raw reply [flat|nested] 23+ messages in thread* Re: [RFC][Patches] Xen 1GB Page Table Support
2010-01-13 4:07 ` Xu, Dongxiao
@ 2010-01-13 16:27 ` Wei Huang
2010-01-14 1:36 ` Xu, Dongxiao
0 siblings, 1 reply; 23+ messages in thread
From: Wei Huang @ 2010-01-13 16:27 UTC (permalink / raw)
To: Xu, Dongxiao
Cc: George Dunlap, xen-devel@lists.xensource.com,
keir.fraser@eu.citrix.com, Tim Deegan
Dongxiao,
Thanks for re-basing the code. Does the new code work for you? I need to
test the new code again on my machine and make sure it doesn't break.
After that, we can ask Keir to push into upstream.
-Wei
Xu, Dongxiao wrote:
> Hi, Wei,
> I digged out this thread from looooong history...
> Do you still have plan to push your 1gb_p2m and 1gb_tool patches into upstream?
> I rebased them to fit the latest upstream code (the 1gb_tools.patch is not changed).
> Comment on that or any new idea? Thanks!
>
> Best Regards,
> -- Dongxiao
>
> Huang2, Wei wrote:
>
>> Here are patches using the middle approach. It handles 1GB pages in
>> PoD by remapping 1GB with 2MB pages & retry. I also added code for 1GB
>> detection. Please comment.
>>
>> Thanks a lot,
>>
>> -Wei
>>
>> -----Original Message-----
>> From: dunlapg@gmail.com [mailto:dunlapg@gmail.com] On Behalf Of George
>> Dunlap
>> Sent: Wednesday, March 18, 2009 12:20 PM
>> To: Huang2, Wei
>> Cc: xen-devel@lists.xensource.com; keir.fraser@eu.citrix.com; Tim
>> Deegan Subject: Re: [Xen-devel] [RFC][Patches] Xen 1GB Page Table
>> Support
>>
>> Thanks for doing this work, Wei -- especially all the extra effort for
>> the PoD integration.
>>
>> One question: How well would you say you've tested the PoD
>> functionality? Or to put it the other way, how much do I need to
>> prioritize testing this before the 3.4 release?
>>
>> It wouldn't be a bad idea to do as you suggested, and break things
>> into 2 meg pages for the PoD case. In order to take the best
>> advantage of this in a PoD scenario, you'd need to have a balloon
>> driver that could allocate 1G of continuous *guest* p2m space, which
>> seems a bit optimistic at this point...
>>
>> -George
>>
>> 2009/3/18 Huang2, Wei <Wei.Huang2@amd.com>:
>>
>>> Current Xen supports 2MB super pages for NPT/EPT. The attached
>>> patches extend this feature to support 1GB pages. The PoD
>>> (populate-on-demand) introduced by George Dunlap made P2M
>>> modification harder. I tried to preserve existing PoD design by
>>> introducing a 1GB PoD cache list.
>>>
>>>
>>>
>>> Note that 1GB PoD can be dropped if we don't care about 1GB when PoD
>>> is enabled. In this case, we can just split 1GB PDPE into 512x2MB
>>> PDE entries and grab pages from PoD super list. That can pretty much
>>> make 1gb_p2m_pod.patch go away.
>>>
>>>
>>>
>>> Any comment/suggestion on design idea will be appreciated.
>>>
>>>
>>>
>>> Thanks,
>>>
>>>
>>>
>>> -Wei
>>>
>>>
>>>
>>>
>>>
>>> The following is the description:
>>>
>>> === 1gb_tools.patch ===
>>>
>>> Extend existing setup_guest() function. Basically, it tries to
>>> allocate 1GB pages whenever available. If this request fails, it
>>> falls back to 2MB. If both fail, then 4KB pages will be used.
>>>
>>>
>>>
>>> === 1gb_p2m.patch ===
>>>
>>> * p2m_next_level()
>>>
>>> Check PSE bit of L3 page table entry. If 1GB is found (PSE=1), we
>>> split 1GB into 512 2MB pages.
>>>
>>>
>>>
>>> * p2m_set_entry()
>>>
>>> Configure the PSE bit of L3 P2M table if page order == 18 (1GB).
>>>
>>>
>>>
>>> * p2m_gfn_to_mfn()
>>>
>>> Add support for 1GB case when doing gfn to mfn translation. When L3
>>> entry is marked as POPULATE_ON_DEMAND, we call
>>> 2m_pod_demand_populate(). Otherwise, we do the regular address
>>> translation (gfn ==> mfn).
>>>
>>>
>>>
>>> * p2m_gfn_to_mfn_current()
>>>
>>> This is similar to p2m_gfn_to_mfn(). When L3 entry s marked as
>>> POPULATE_ON_DEMAND, it demands a populate using
>>> p2m_pod_demand_populate(). Otherwise, it does a normal translation.
>>> 1GB page is taken into consideration.
>>>
>>>
>>>
>>> * set_p2m_entry()
>>>
>>> Request 1GB page
>>>
>>>
>>>
>>> * audit_p2m()
>>>
>>> Support 1GB while auditing p2m table.
>>>
>>>
>>>
>>> * p2m_change_type_global()
>>>
>>> Deal with 1GB page when changing global page type.
>>>
>>>
>>>
>>> === 1gb_p2m_pod.patch ===
>>>
>>> * xen/include/asm-x86/p2m.h
>>>
>>> Minor change to deal with PoD. It separates super page cache list
>>> into 2MB and 1GB lists. Similarly, we record last gpfn of sweeping
>>> for both 2MB and 1GB.
>>>
>>>
>>>
>>> * p2m_pod_cache_add()
>>>
>>> Check page order and add 1GB super page into PoD 1GB cache list.
>>>
>>>
>>>
>>> * p2m_pod_cache_get()
>>>
>>> Grab a page from cache list. It tries to break 1GB page into 512 2MB
>>> pages if 2MB PoD list is empty. Similarly, 4KB can be requested from
>>> super pages. The breaking order is 2MB then 1GB.
>>>
>>>
>>>
>>> * p2m_pod_cache_target()
>>>
>>> This function is used to set PoD cache size. To increase PoD target,
>>> we try to allocate 1GB from xen domheap. If this fails, we try 2MB.
>>> If both fail, we try 4KB which is guaranteed to work.
>>>
>>>
>>>
>>> To decrease the target, we use a similar approach. We first try to
>>> free 1GB pages from 1GB PoD cache list. If such request fails, we
>>> try 2MB PoD cache list. If both fail, we try 4KB list.
>>>
>>>
>>>
>>> * p2m_pod_zero_check_superpage_1gb()
>>>
>>> This adds a new function to check for 1GB page. This function is
>>> similar to p2m_pod_zero_check_superpage_2mb().
>>>
>>>
>>>
>>> * p2m_pod_zero_check_superpage_1gb()
>>>
>>> We add a new function to sweep 1GB page from guest memory. This is
>>> the same as p2m_pod_zero_check_superpage_2mb().
>>>
>>>
>>>
>>> * p2m_pod_demand_populate()
>>>
>>> The trick of this function is to do remap_and_retry if
>>> p2m_pod_cache_get() fails. When p2m_pod_get() fails, this function
>>> will splits p2m table entry into smaller ones (e.g. 1GB ==> 2MB or
>>> 2MB ==> 4KB). That can guarantee populate demands always work.
>>>
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> Xen-devel mailing list
>>> Xen-devel@lists.xensource.com
>>> http://lists.xensource.com/xen-devel
^ permalink raw reply [flat|nested] 23+ messages in thread
* RE: [RFC][Patches] Xen 1GB Page Table Support
2010-01-13 16:27 ` Wei Huang
@ 2010-01-14 1:36 ` Xu, Dongxiao
0 siblings, 0 replies; 23+ messages in thread
From: Xu, Dongxiao @ 2010-01-14 1:36 UTC (permalink / raw)
To: Wei Huang
Cc: George Dunlap, xen-devel@lists.xensource.com,
keir.fraser@eu.citrix.com, Tim Deegan
Wei,
Yes, basically it works for me. However I didn't test it too much.
For example, I haven't tested the PoD functionality with the patch.
Thanks!
Dongxiao
Wei Huang wrote:
> Dongxiao,
>
> Thanks for re-basing the code. Does the new code work for you? I need
> to test the new code again on my machine and make sure it doesn't
> break. After that, we can ask Keir to push into upstream.
>
> -Wei
>
>
> Xu, Dongxiao wrote:
>> Hi, Wei,
>> I digged out this thread from looooong history...
>> Do you still have plan to push your 1gb_p2m and 1gb_tool patches
>> into upstream? I rebased them to fit the latest upstream code (the
>> 1gb_tools.patch is not changed). Comment on that or any new idea?
>> Thanks!
>>
>> Best Regards,
>> -- Dongxiao
>>
>> Huang2, Wei wrote:
>>
>>> Here are patches using the middle approach. It handles 1GB pages in
>>> PoD by remapping 1GB with 2MB pages & retry. I also added code for
>>> 1GB detection. Please comment.
>>>
>>> Thanks a lot,
>>>
>>> -Wei
>>>
>>> -----Original Message-----
>>> From: dunlapg@gmail.com [mailto:dunlapg@gmail.com] On Behalf Of
>>> George Dunlap Sent: Wednesday, March 18, 2009 12:20 PM
>>> To: Huang2, Wei
>>> Cc: xen-devel@lists.xensource.com; keir.fraser@eu.citrix.com; Tim
>>> Deegan Subject: Re: [Xen-devel] [RFC][Patches] Xen 1GB Page Table
>>> Support
>>>
>>> Thanks for doing this work, Wei -- especially all the extra effort
>>> for the PoD integration.
>>>
>>> One question: How well would you say you've tested the PoD
>>> functionality? Or to put it the other way, how much do I need to
>>> prioritize testing this before the 3.4 release?
>>>
>>> It wouldn't be a bad idea to do as you suggested, and break things
>>> into 2 meg pages for the PoD case. In order to take the best
>>> advantage of this in a PoD scenario, you'd need to have a balloon
>>> driver that could allocate 1G of continuous *guest* p2m space, which
>>> seems a bit optimistic at this point...
>>>
>>> -George
>>>
>>> 2009/3/18 Huang2, Wei <Wei.Huang2@amd.com>:
>>>
>>>> Current Xen supports 2MB super pages for NPT/EPT. The attached
>>>> patches extend this feature to support 1GB pages. The PoD
>>>> (populate-on-demand) introduced by George Dunlap made P2M
>>>> modification harder. I tried to preserve existing PoD design by
>>>> introducing a 1GB PoD cache list.
>>>>
>>>>
>>>>
>>>> Note that 1GB PoD can be dropped if we don't care about 1GB when
>>>> PoD is enabled. In this case, we can just split 1GB PDPE into
>>>> 512x2MB PDE entries and grab pages from PoD super list. That can
>>>> pretty much make 1gb_p2m_pod.patch go away.
>>>>
>>>>
>>>>
>>>> Any comment/suggestion on design idea will be appreciated.
>>>>
>>>>
>>>>
>>>> Thanks,
>>>>
>>>>
>>>>
>>>> -Wei
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> The following is the description:
>>>>
>>>> === 1gb_tools.patch ===
>>>>
>>>> Extend existing setup_guest() function. Basically, it tries to
>>>> allocate 1GB pages whenever available. If this request fails, it
>>>> falls back to 2MB. If both fail, then 4KB pages will be used.
>>>>
>>>>
>>>>
>>>> === 1gb_p2m.patch ===
>>>>
>>>> * p2m_next_level()
>>>>
>>>> Check PSE bit of L3 page table entry. If 1GB is found (PSE=1), we
>>>> split 1GB into 512 2MB pages.
>>>>
>>>>
>>>>
>>>> * p2m_set_entry()
>>>>
>>>> Configure the PSE bit of L3 P2M table if page order == 18 (1GB).
>>>>
>>>>
>>>>
>>>> * p2m_gfn_to_mfn()
>>>>
>>>> Add support for 1GB case when doing gfn to mfn translation. When L3
>>>> entry is marked as POPULATE_ON_DEMAND, we call
>>>> 2m_pod_demand_populate(). Otherwise, we do the regular address
>>>> translation (gfn ==> mfn).
>>>>
>>>>
>>>>
>>>> * p2m_gfn_to_mfn_current()
>>>>
>>>> This is similar to p2m_gfn_to_mfn(). When L3 entry s marked as
>>>> POPULATE_ON_DEMAND, it demands a populate using
>>>> p2m_pod_demand_populate(). Otherwise, it does a normal translation.
>>>> 1GB page is taken into consideration.
>>>>
>>>>
>>>>
>>>> * set_p2m_entry()
>>>>
>>>> Request 1GB page
>>>>
>>>>
>>>>
>>>> * audit_p2m()
>>>>
>>>> Support 1GB while auditing p2m table.
>>>>
>>>>
>>>>
>>>> * p2m_change_type_global()
>>>>
>>>> Deal with 1GB page when changing global page type.
>>>>
>>>>
>>>>
>>>> === 1gb_p2m_pod.patch ===
>>>>
>>>> * xen/include/asm-x86/p2m.h
>>>>
>>>> Minor change to deal with PoD. It separates super page cache list
>>>> into 2MB and 1GB lists. Similarly, we record last gpfn of sweeping
>>>> for both 2MB and 1GB.
>>>>
>>>>
>>>>
>>>> * p2m_pod_cache_add()
>>>>
>>>> Check page order and add 1GB super page into PoD 1GB cache list.
>>>>
>>>>
>>>>
>>>> * p2m_pod_cache_get()
>>>>
>>>> Grab a page from cache list. It tries to break 1GB page into 512
>>>> 2MB pages if 2MB PoD list is empty. Similarly, 4KB can be
>>>> requested from super pages. The breaking order is 2MB then 1GB.
>>>>
>>>>
>>>>
>>>> * p2m_pod_cache_target()
>>>>
>>>> This function is used to set PoD cache size. To increase PoD
>>>> target, we try to allocate 1GB from xen domheap. If this fails, we
>>>> try 2MB. If both fail, we try 4KB which is guaranteed to work.
>>>>
>>>>
>>>>
>>>> To decrease the target, we use a similar approach. We first try to
>>>> free 1GB pages from 1GB PoD cache list. If such request fails, we
>>>> try 2MB PoD cache list. If both fail, we try 4KB list.
>>>>
>>>>
>>>>
>>>> * p2m_pod_zero_check_superpage_1gb()
>>>>
>>>> This adds a new function to check for 1GB page. This function is
>>>> similar to p2m_pod_zero_check_superpage_2mb().
>>>>
>>>>
>>>>
>>>> * p2m_pod_zero_check_superpage_1gb()
>>>>
>>>> We add a new function to sweep 1GB page from guest memory. This is
>>>> the same as p2m_pod_zero_check_superpage_2mb().
>>>>
>>>>
>>>>
>>>> * p2m_pod_demand_populate()
>>>>
>>>> The trick of this function is to do remap_and_retry if
>>>> p2m_pod_cache_get() fails. When p2m_pod_get() fails, this function
>>>> will splits p2m table entry into smaller ones (e.g. 1GB ==> 2MB or
>>>> 2MB ==> 4KB). That can guarantee populate demands always work.
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> Xen-devel mailing list
>>>> Xen-devel@lists.xensource.com
>>>> http://lists.xensource.com/xen-devel
^ permalink raw reply [flat|nested] 23+ messages in thread
end of thread, other threads:[~2010-01-14 1:36 UTC | newest]
Thread overview: 23+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2009-03-18 15:48 [RFC][Patches] Xen 1GB Page Table Support Huang2, Wei
2009-03-18 17:20 ` George Dunlap
2009-03-18 17:32 ` Keir Fraser
2009-03-18 17:45 ` Huang2, Wei
2009-03-18 19:15 ` Keir Fraser
2009-03-18 17:37 ` Huang2, Wei
2009-03-19 8:07 ` Huang2, Wei
2009-03-19 14:17 ` Dan Magenheimer
2009-03-19 18:51 ` Wei Huang
2009-03-19 19:56 ` Dan Magenheimer
2009-03-19 21:07 ` Wei Huang
2009-03-20 9:45 ` George Dunlap
2009-03-20 13:40 ` Dan Magenheimer
2009-03-20 13:56 ` Wei Huang
2009-03-20 13:59 ` Gianluca Guida
2009-03-20 14:25 ` George Dunlap
2009-03-20 14:21 ` Gianluca Guida
2009-03-20 18:16 ` Gianluca Guida
2009-03-20 18:32 ` Huang2, Wei
2009-05-19 0:55 ` Keir Fraser
2010-01-13 4:07 ` Xu, Dongxiao
2010-01-13 16:27 ` Wei Huang
2010-01-14 1:36 ` Xu, Dongxiao
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.