Linux kernel development

Konrad Rzeszutek Wilk | 31 Jul 2012 16:43

Picon

[PATCH] Boot PV guests with more than 128GB (v2) for 3.7

Changelog:
Since v1: [http://lists.xen.org/archives/html/xen-devel/2012-07/msg01561.html]
 - added more comments, and #ifdefs
 - squashed The L4 and L4, L3, and L2 recycle patches together
 - Added Acked-by's

The explanation of these patches is exactly what v1 had:

The details of this problem are nicely explained in:

 [PATCH 4/6] xen/p2m: Add logic to revector a P2M tree to use __va
 [PATCH 5/6] xen/mmu: Copy and revector the P2M tree.
 [PATCH 6/6] xen/mmu: Remove from __ka space PMD entries for

and the supporting patches are just nice optimizations. Pasting in
what those patches mentioned:

During bootup Xen supplies us with a P2M array. It sticks
it right after the ramdisk, as can be seen with a 128GB PV guest:

(certain parts removed for clarity):
xc_dom_build_image: called
xc_dom_alloc_segment:   kernel       : 0xffffffff81000000 -> 0xffffffff81e43000 
 (pfn 0x1000 + 0xe43 pages)
xc_dom_pfn_to_ptr: domU mapping: pfn 0x1000+0xe43 at 0x7f097d8bf000
xc_dom_alloc_segment:   ramdisk      : 0xffffffff81e43000 -> 0xffffffff925c7000 
 (pfn 0x1e43 + 0x10784 pages)
xc_dom_pfn_to_ptr: domU mapping: pfn 0x1e43+0x10784 at 0x7f0952dd2000
xc_dom_alloc_segment:   phys2mach    : 0xffffffff925c7000 -> 0xffffffffa25c7000 
 (pfn 0x125c7 + 0x10000 pages)

(Continue reading)

Konrad Rzeszutek Wilk | 31 Jul 2012 16:43

Picon

[PATCH 6/6] xen/mmu: Remove from __ka space PMD entries for pagetables.

Please first read the description in "xen/mmu: Copy and revector the
P2M tree."

At this stage, the __ka address space (which is what the old
P2M tree was using) is partially disassembled. The cleanup_highmap
has removed the PMD entries from 0-16MB and anything past _brk_end
up to the max_pfn_mapped (which is the end of the ramdisk).

The xen_remove_p2m_tree and code around has ripped out the __ka for
the old P2M array.

Here we continue on doing it to where the Xen page-tables were.
It is safe to do it, as the page-tables are addressed using __va.
For good measure we delete anything that is within MODULES_VADDR
and up to the end of the PMD.

At this point the __ka only contains PMD entries for the start
of the kernel up to __brk.

[v1: Per Stefano's suggestion wrapped the MODULES_VADDR in debug]
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk <at> oracle.com>
---
 arch/x86/xen/mmu.c |   19 +++++++++++++++++++
 1 files changed, 19 insertions(+), 0 deletions(-)

diff --git a/arch/x86/xen/mmu.c b/arch/x86/xen/mmu.c
index 9358b75..fa4d208 100644
--- a/arch/x86/xen/mmu.c
+++ b/arch/x86/xen/mmu.c
 <at>  <at>  -1240,6 +1240,25  <at>  <at>  static void __init xen_pagetable_setup_done(pgd_t *base)

(Continue reading)

Konrad Rzeszutek Wilk | 31 Jul 2012 16:43

Picon

[PATCH 1/6] xen/mmu: use copy_page instead of memcpy.

After all, this is what it is there for.

Acked-by: Jan Beulich <jbeulich <at> suse.com>
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk <at> oracle.com>
---
 arch/x86/xen/mmu.c |   13 ++++++-------
 1 files changed, 6 insertions(+), 7 deletions(-)

diff --git a/arch/x86/xen/mmu.c b/arch/x86/xen/mmu.c
index 6ba6100..7247e5a 100644
--- a/arch/x86/xen/mmu.c
+++ b/arch/x86/xen/mmu.c
 <at>  <at>  -1754,14 +1754,14  <at>  <at>  void __init xen_setup_kernel_pagetable(pgd_t *pgd, unsigned long max_pfn)
 	 * it will be also modified in the __ka space! (But if you just
 	 * modify the PMD table to point to other PTE's or none, then you
 	 * are OK - which is what cleanup_highmap does) */
-	memcpy(level2_ident_pgt, l2, sizeof(pmd_t) * PTRS_PER_PMD);
+	copy_page(level2_ident_pgt, l2);
 	/* Graft it onto L4[511][511] */
-	memcpy(level2_kernel_pgt, l2, sizeof(pmd_t) * PTRS_PER_PMD);
+	copy_page(level2_kernel_pgt, l2);

 	/* Get [511][510] and graft that in level2_fixmap_pgt */
 	l3 = m2v(pgd[pgd_index(__START_KERNEL_map + PMD_SIZE)].pgd);
 	l2 = m2v(l3[pud_index(__START_KERNEL_map + PMD_SIZE)].pud);
-	memcpy(level2_fixmap_pgt, l2, sizeof(pmd_t) * PTRS_PER_PMD);
+	copy_page(level2_fixmap_pgt, l2);
 	/* Note that we don't do anything with level1_fixmap_pgt which
 	 * we don't need. */

(Continue reading)

Konrad Rzeszutek Wilk | 31 Jul 2012 16:43

Picon

[PATCH 2/6] xen/mmu: For 64-bit do not call xen_map_identity_early

B/c we do not need it. During the startup the Xen provides
us with all the memory mapped that we need to function.

Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk <at> oracle.com>
---
 arch/x86/xen/mmu.c |   11 +++++------
 1 files changed, 5 insertions(+), 6 deletions(-)

diff --git a/arch/x86/xen/mmu.c b/arch/x86/xen/mmu.c
index 7247e5a..a59070b 100644
--- a/arch/x86/xen/mmu.c
+++ b/arch/x86/xen/mmu.c
 <at>  <at>  -84,6 +84,7  <at>  <at> 
  */
 DEFINE_SPINLOCK(xen_reservation_lock);

+#ifdef CONFIG_X86_32
 /*
  * Identity map, in addition to plain kernel map.  This needs to be
  * large enough to allocate page table pages to allocate the rest.
 <at>  <at>  -91,7 +92,7  <at>  <at>  DEFINE_SPINLOCK(xen_reservation_lock);
  */
 #define LEVEL1_IDENT_ENTRIES	(PTRS_PER_PTE * 4)
 static RESERVE_BRK_ARRAY(pte_t, level1_ident_pgt, LEVEL1_IDENT_ENTRIES);
-
+#endif
 #ifdef CONFIG_X86_64
 /* l3 pud for userspace vsyscall mapping */
 static pud_t level3_user_vsyscall[PTRS_PER_PUD] __page_aligned_bss;
 <at>  <at>  -1628,7 +1629,7  <at>  <at>  static void set_page_prot(void *addr, pgprot_t prot)

(Continue reading)

Konrad Rzeszutek Wilk | 31 Jul 2012 16:43

Picon

[PATCH 3/6] xen/mmu: Recycle the Xen provided L4, L3, and L2 pages

As we are not using them. We end up only using the L1 pagetables
and grafting those to our page-tables.

[v1: Per Stefano's suggestion squashed two commits]
[v2: Per Stefano's suggestion simplified loop]
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk <at> oracle.com>
---
 arch/x86/xen/mmu.c |   40 +++++++++++++++++++++++++++++++++-------
 1 files changed, 33 insertions(+), 7 deletions(-)

diff --git a/arch/x86/xen/mmu.c b/arch/x86/xen/mmu.c
index a59070b..de4b8fd 100644
--- a/arch/x86/xen/mmu.c
+++ b/arch/x86/xen/mmu.c
 <at>  <at>  -1708,7 +1708,20  <at>  <at>  static void convert_pfn_mfn(void *v)
 	for (i = 0; i < PTRS_PER_PTE; i++)
 		pte[i] = xen_make_pte(pte[i].pte);
 }
-
+static __init check_pt_base(unsigned long *pt_base, unsigned long *pt_end,
+			    unsigned long addr)
+{
+	if (pt_base == PFN_DOWN(__pa(addr))) {
+		set_page_prot((void *)addr, PAGE_KERNEL);
+		clear_page((void *)addr);
+		*pt_base++;
+	}
+	if (pt_end == PFN_DOWN(__pa(addr))) {
+		set_page_prot((void *)addr, PAGE_KERNEL);
+		clear_page((void *)addr);

(Continue reading)

Konrad Rzeszutek Wilk | 31 Jul 2012 16:43

Picon

[PATCH 4/6] xen/p2m: Add logic to revector a P2M tree to use __va leafs.

During bootup Xen supplies us with a P2M array. It sticks
it right after the ramdisk, as can be seen with a 128GB PV guest:

(certain parts removed for clarity):
xc_dom_build_image: called
xc_dom_alloc_segment:   kernel       : 0xffffffff81000000 -> 0xffffffff81e43000  (pfn 0x1000 + 0xe43 pages)
xc_dom_pfn_to_ptr: domU mapping: pfn 0x1000+0xe43 at 0x7f097d8bf000
xc_dom_alloc_segment:   ramdisk      : 0xffffffff81e43000 -> 0xffffffff925c7000  (pfn 0x1e43 + 0x10784 pages)
xc_dom_pfn_to_ptr: domU mapping: pfn 0x1e43+0x10784 at 0x7f0952dd2000
xc_dom_alloc_segment:   phys2mach    : 0xffffffff925c7000 -> 0xffffffffa25c7000  (pfn 0x125c7 + 0x10000 pages)
xc_dom_pfn_to_ptr: domU mapping: pfn 0x125c7+0x10000 at 0x7f0942dd2000
xc_dom_alloc_page   :   start info   : 0xffffffffa25c7000 (pfn 0x225c7)
xc_dom_alloc_page   :   xenstore     : 0xffffffffa25c8000 (pfn 0x225c8)
xc_dom_alloc_page   :   console      : 0xffffffffa25c9000 (pfn 0x225c9)
nr_page_tables: 0x0000ffffffffffff/48: 0xffff000000000000 -> 0xffffffffffffffff, 1 table(s)
nr_page_tables: 0x0000007fffffffff/39: 0xffffff8000000000 -> 0xffffffffffffffff, 1 table(s)
nr_page_tables: 0x000000003fffffff/30: 0xffffffff80000000 -> 0xffffffffbfffffff, 1 table(s)
nr_page_tables: 0x00000000001fffff/21: 0xffffffff80000000 -> 0xffffffffa27fffff, 276 table(s)
xc_dom_alloc_segment:   page tables  : 0xffffffffa25ca000 -> 0xffffffffa26e1000  (pfn 0x225ca + 0x117 pages)
xc_dom_pfn_to_ptr: domU mapping: pfn 0x225ca+0x117 at 0x7f097d7a8000
xc_dom_alloc_page   :   boot stack   : 0xffffffffa26e1000 (pfn 0x226e1)
xc_dom_build_image  : virt_alloc_end : 0xffffffffa26e2000
xc_dom_build_image  : virt_pgtab_end : 0xffffffffa2800000

So the physical memory and virtual (using __START_KERNEL_map addresses)
layout looks as so:

  phys                             __ka
/------------\                   /-------------------\
| 0          | empty             | 0xffffffff80000000|

(Continue reading)

Konrad Rzeszutek Wilk | 31 Jul 2012 16:43

Picon

[PATCH 5/6] xen/mmu: Copy and revector the P2M tree.

Please first read the description in "xen/p2m: Add logic to revector a
P2M tree to use __va leafs" patch.

The 'xen_revector_p2m_tree()' function allocates a new P2M tree
copies the contents of the old one in it, and returns the new one.

At this stage, the __ka address space (which is what the old
P2M tree was using) is partially disassembled. The cleanup_highmap
has removed the PMD entries from 0-16MB and anything past _brk_end
up to the max_pfn_mapped (which is the end of the ramdisk).

We have revectored the P2M tree (and the one for save/restore as well)
to use new shiny __va address to new MFNs. The xen_start_info
has been taken care of already in 'xen_setup_kernel_pagetable()' and
xen_start_info->shared_info in 'xen_setup_shared_info()', so
we are free to roam and delete PMD entries - which is exactly what
we are going to do. We rip out the __ka for the old P2M array.

Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk <at> oracle.com>
---
 arch/x86/xen/mmu.c |   57 ++++++++++++++++++++++++++++++++++++++++++++++++++++
 1 files changed, 57 insertions(+), 0 deletions(-)

diff --git a/arch/x86/xen/mmu.c b/arch/x86/xen/mmu.c
index de4b8fd..9358b75 100644
--- a/arch/x86/xen/mmu.c
+++ b/arch/x86/xen/mmu.c
 <at>  <at>  -1183,9 +1183,64  <at>  <at>  static __init void xen_mapping_pagetable_reserve(u64 start, u64 end)

 static void xen_post_allocator_init(void);

(Continue reading)

Konrad Rzeszutek Wilk | 1 Aug 2012 17:50

Picon

Re: [PATCH] Boot PV guests with more than 128GB (v2) for 3.7

On Tue, Jul 31, 2012 at 10:43:18AM -0400, Konrad Rzeszutek Wilk wrote:
> Changelog:
> Since v1: [http://lists.xen.org/archives/html/xen-devel/2012-07/msg01561.html]
>  - added more comments, and #ifdefs
>  - squashed The L4 and L4, L3, and L2 recycle patches together
>  - Added Acked-by's
> 
> The explanation of these patches is exactly what v1 had:
> 
> The details of this problem are nicely explained in:
> 
>  [PATCH 4/6] xen/p2m: Add logic to revector a P2M tree to use __va
>  [PATCH 5/6] xen/mmu: Copy and revector the P2M tree.
>  [PATCH 6/6] xen/mmu: Remove from __ka space PMD entries for
> 
> and the supporting patches are just nice optimizations. Pasting in
> what those patches mentioned:

With these patches I've gotten it to boot up to 384GB. Around that area
something weird happens - mainly the pagetables that the toolstack allocated
seems to have missing data. I hadn't looked in details, but this is what
domain builder tells me:

xc_dom_alloc_segment:   ramdisk      : 0xffffffff82278000 -> 0xffffffff930b4000  (pfn 0x2278 + 0x10e3c pages)
xc_dom_malloc            : 1621 kB
xc_dom_pfn_to_ptr: domU mapping: pfn 0x2278+0x10e3c at 0x7fb0853a2000
xc_dom_do_gunzip: unzip ok, 0x4ba831c -> 0x10e3be10
xc_dom_alloc_segment:   phys2mach    : 0xffffffff930b4000 -> 0xffffffffc30b4000  (pfn 0x130b4 + 0x30000 pages)
xc_dom_malloc            : 4608 kB
xc_dom_pfn_to_ptr: domU mapping: pfn 0x130b4+0x30000 at 0x7fb0553a2000

(Continue reading)

Jan Beulich | 2 Aug 2012 11:05

Re: [PATCH] Boot PV guests with more than 128GB (v2) for 3.7

>>> On 01.08.12 at 17:50, Konrad Rzeszutek Wilk <konrad.wilk <at> oracle.com> wrote:
> With these patches I've gotten it to boot up to 384GB. Around that area
> something weird happens - mainly the pagetables that the toolstack allocated
> seems to have missing data. I hadn't looked in details, but this is what
> domain builder tells me:
> 
> 
> xc_dom_alloc_segment:   ramdisk      : 0xffffffff82278000 -> 
> 0xffffffff930b4000  (pfn 0x2278 + 0x10e3c pages)
> xc_dom_malloc            : 1621 kB
> xc_dom_pfn_to_ptr: domU mapping: pfn 0x2278+0x10e3c at 0x7fb0853a2000
> xc_dom_do_gunzip: unzip ok, 0x4ba831c -> 0x10e3be10
> xc_dom_alloc_segment:   phys2mach    : 0xffffffff930b4000 -> 
> 0xffffffffc30b4000  (pfn 0x130b4 + 0x30000 pages)
> xc_dom_malloc            : 4608 kB
> xc_dom_pfn_to_ptr: domU mapping: pfn 0x130b4+0x30000 at 0x7fb0553a2000
> xc_dom_alloc_page   :   start info   : 0xffffffffc30b4000 (pfn 0x430b4)
> xc_dom_alloc_page   :   xenstore     : 0xffffffffc30b5000 (pfn 0x430b5)
> xc_dom_alloc_page   :   console      : 0xffffffffc30b6000 (pfn 0x430b6)
> nr_page_tables: 0x0000ffffffffffff/48: 0xffff000000000000 -> 
> 0xffffffffffffffff, 1 table(s)
> nr_page_tables: 0x0000007fffffffff/39: 0xffffff8000000000 -> 
> 0xffffffffffffffff, 1 table(s)
> nr_page_tables: 0x000000003fffffff/30: 0xffffffff80000000 -> 
> 0xffffffffffffffff, 2 table(s)
> nr_page_tables: 0x00000000001fffff/21: 0xffffffff80000000 -> 
> 0xffffffffc33fffff, 538 table(s)
> xc_dom_alloc_segment:   page tables  : 0xffffffffc30b7000 -> 
> 0xffffffffc32d5000  (pfn 0x430b7 + 0x21e pages)
> xc_dom_pfn_to_ptr: domU mapping: pfn 0x430b7+0x21e at 0x7fb055184000

(Continue reading)

Konrad Rzeszutek Wilk | 2 Aug 2012 16:17

Picon

Re: [PATCH] Boot PV guests with more than 128GB (v2) for 3.7

On Thu, Aug 02, 2012 at 10:05:27AM +0100, Jan Beulich wrote:
> >>> On 01.08.12 at 17:50, Konrad Rzeszutek Wilk <konrad.wilk <at> oracle.com> wrote:
> > With these patches I've gotten it to boot up to 384GB. Around that area
> > something weird happens - mainly the pagetables that the toolstack allocated
> > seems to have missing data. I hadn't looked in details, but this is what
> > domain builder tells me:
> > 
> > 
> > xc_dom_alloc_segment:   ramdisk      : 0xffffffff82278000 -> 
> > 0xffffffff930b4000  (pfn 0x2278 + 0x10e3c pages)
> > xc_dom_malloc            : 1621 kB
> > xc_dom_pfn_to_ptr: domU mapping: pfn 0x2278+0x10e3c at 0x7fb0853a2000
> > xc_dom_do_gunzip: unzip ok, 0x4ba831c -> 0x10e3be10
> > xc_dom_alloc_segment:   phys2mach    : 0xffffffff930b4000 -> 
> > 0xffffffffc30b4000  (pfn 0x130b4 + 0x30000 pages)
> > xc_dom_malloc            : 4608 kB
> > xc_dom_pfn_to_ptr: domU mapping: pfn 0x130b4+0x30000 at 0x7fb0553a2000
> > xc_dom_alloc_page   :   start info   : 0xffffffffc30b4000 (pfn 0x430b4)
> > xc_dom_alloc_page   :   xenstore     : 0xffffffffc30b5000 (pfn 0x430b5)
> > xc_dom_alloc_page   :   console      : 0xffffffffc30b6000 (pfn 0x430b6)
> > nr_page_tables: 0x0000ffffffffffff/48: 0xffff000000000000 -> 
> > 0xffffffffffffffff, 1 table(s)
> > nr_page_tables: 0x0000007fffffffff/39: 0xffffff8000000000 -> 
> > 0xffffffffffffffff, 1 table(s)
> > nr_page_tables: 0x000000003fffffff/30: 0xffffffff80000000 -> 
> > 0xffffffffffffffff, 2 table(s)
> > nr_page_tables: 0x00000000001fffff/21: 0xffffffff80000000 -> 
> > 0xffffffffc33fffff, 538 table(s)
> > xc_dom_alloc_segment:   page tables  : 0xffffffffc30b7000 -> 
> > 0xffffffffc32d5000  (pfn 0x430b7 + 0x21e pages)

(Continue reading)

Mukesh Rathor | 3 Aug 2012 01:04

Picon

Re: [PATCH] Boot PV guests with more than 128GB (v2) for 3.7

On Thu, 2 Aug 2012 10:17:10 -0400
Konrad Rzeszutek Wilk <konrad.wilk <at> oracle.com> wrote:

> On Thu, Aug 02, 2012 at 10:05:27AM +0100, Jan Beulich wrote:
> > >>> On 01.08.12 at 17:50, Konrad Rzeszutek Wilk
> > >>> <konrad.wilk <at> oracle.com> wrote:
> > > With these patches I've gotten it to boot up to 384GB. Around
> > > that area something weird happens - mainly the pagetables that
> > > the toolstack allocated seems to have missing data. I hadn't
> > > looked in details, but this is what domain builder tells me:
> > > 
> > > 
> > > xc_dom_alloc_segment:   ramdisk      : 0xffffffff82278000 -> 
> > > 0xffffffff930b4000  (pfn 0x2278 + 0x10e3c pages)
> > > xc_dom_malloc            : 1621 kB
> > > xc_dom_pfn_to_ptr: domU mapping: pfn 0x2278+0x10e3c at
> > > 0x7fb0853a2000 xc_dom_do_gunzip: unzip ok, 0x4ba831c -> 0x10e3be10
> > > xc_dom_alloc_segment:   phys2mach    : 0xffffffff930b4000 -> 
> > > 0xffffffffc30b4000  (pfn 0x130b4 + 0x30000 pages)
> > > xc_dom_malloc            : 4608 kB
> > > xc_dom_pfn_to_ptr: domU mapping: pfn 0x130b4+0x30000 at
> > > 0x7fb0553a2000 xc_dom_alloc_page   :   start info   :
> > > 0xffffffffc30b4000 (pfn 0x430b4) xc_dom_alloc_page   :
> > > xenstore     : 0xffffffffc30b5000 (pfn 0x430b5)
> > > xc_dom_alloc_page   :   console      : 0xffffffffc30b6000 (pfn
> > > 0x430b6) nr_page_tables: 0x0000ffffffffffff/48:
> > > 0xffff000000000000 -> 0xffffffffffffffff, 1 table(s)
> > > nr_page_tables: 0x0000007fffffffff/39: 0xffffff8000000000 ->
> > > 0xffffffffffffffff, 1 table(s) nr_page_tables:
> > > 0x000000003fffffff/30: 0xffffffff80000000 -> 0xffffffffffffffff,

(Continue reading)

Konrad Rzeszutek Wilk | 3 Aug 2012 15:30

Re: [PATCH] Boot PV guests with more than 128GB (v2) for 3.7

> > > > Note it is is 0xffffffffc30b4000 - so already past the
> > > > level2_kernel_pgt (L3[510]
> > > > and in level2_fixmap_pgt territory (L3[511]).
> > > > 
> > > > At that stage we are still operating using the Xen provided
> > > > pagetable - which look to have the L4[511][511] empty! Which
> > > > sounds to me like a Xen tool-stack problem? Jan, have you seen
> > > > something similar to this?
> > > 
> > > No we haven't, but I also don't think anyone tried to create as
> > > big a DomU. I was, however, under the impression that DomU-s
> > > this big had been created at Oracle before. Or was that only up
> > > to 256Gb perhaps?
> > 
> > Mukesh do you recall? Was it with OVM2.2.2 which was 3.4 based?
> > It might be that we did not have the 1TB hardware at that time yet.
> 
> Yes, in ovm2.x, I debugged/booted upto 500GB domU. So something
> got broken after it looks like. I can debug later if it becomes hot. 

I got the kernel part fixed but its the toolstack that got bugs in it.
If you recall - where there any patches in the toolstack for this or
did you just concentrate on the kernel?
Thanks!

Jan Beulich | 3 Aug 2012 15:54

Re: [PATCH] Boot PV guests with more than 128GB (v2) for 3.7

>>> On 03.08.12 at 15:30, Konrad Rzeszutek Wilk <konrad <at> darnok.org> wrote:
>> > > > Note it is is 0xffffffffc30b4000 - so already past the
>> > > > level2_kernel_pgt (L3[510]
>> > > > and in level2_fixmap_pgt territory (L3[511]).
>> > > > 
>> > > > At that stage we are still operating using the Xen provided
>> > > > pagetable - which look to have the L4[511][511] empty! Which
>> > > > sounds to me like a Xen tool-stack problem? Jan, have you seen
>> > > > something similar to this?
>> > > 
>> > > No we haven't, but I also don't think anyone tried to create as
>> > > big a DomU. I was, however, under the impression that DomU-s
>> > > this big had been created at Oracle before. Or was that only up
>> > > to 256Gb perhaps?
>> > 
>> > Mukesh do you recall? Was it with OVM2.2.2 which was 3.4 based?
>> > It might be that we did not have the 1TB hardware at that time yet.
>> 
>> Yes, in ovm2.x, I debugged/booted upto 500GB domU. So something
>> got broken after it looks like. I can debug later if it becomes hot. 
> 
> I got the kernel part fixed but its the toolstack that got bugs in it.

So did you try the suggested fix? Or are you waiting for me to
put this in patch form?

Jan

> If you recall - where there any patches in the toolstack for this or
> did you just concentrate on the kernel?

(Continue reading)

Mukesh Rathor | 3 Aug 2012 20:37

Picon

Re: [PATCH] Boot PV guests with more than 128GB (v2) for 3.7

On Fri, 3 Aug 2012 09:30:01 -0400
Konrad Rzeszutek Wilk <konrad <at> darnok.org> wrote:

> > > > > Note it is is 0xffffffffc30b4000 - so already past the
> > > > > level2_kernel_pgt (L3[510]
> > > > > and in level2_fixmap_pgt territory (L3[511]).
> > > > > 
> > > > > At that stage we are still operating using the Xen provided
> > > > > pagetable - which look to have the L4[511][511] empty! Which
> > > > > sounds to me like a Xen tool-stack problem? Jan, have you seen
> > > > > something similar to this?
> > > > 
> > > > No we haven't, but I also don't think anyone tried to create as
> > > > big a DomU. I was, however, under the impression that DomU-s
> > > > this big had been created at Oracle before. Or was that only up
> > > > to 256Gb perhaps?
> > > 
> > > Mukesh do you recall? Was it with OVM2.2.2 which was 3.4 based?
> > > It might be that we did not have the 1TB hardware at that time
> > > yet.
> > 
> > Yes, in ovm2.x, I debugged/booted upto 500GB domU. So something
> > got broken after it looks like. I can debug later if it becomes
> > hot. 
> 
> I got the kernel part fixed but its the toolstack that got bugs in it.
> If you recall - where there any patches in the toolstack for this or
> did you just concentrate on the kernel?

Ah, I remember, it was issue in tool stack, xm, so I punted it for

(Continue reading)

Return

Return to gmane.linux.kernel.

Advertisement

Search Archive

Language

Change language

Options

Current view: Threads only / Showing only 20 lines / Not hiding cited text.
Change to All messages, whole messages, or hide cited text.

Post a message
NNTP Newsgroup
Classic Gmane web interface
XML

XML

RSS Feed
List Information

About Gmane