Re: [Xen-ia64-devel] Re: [PATCH][RFC] fix dom0 builder TAKE3
Hi, Isaku On our PRIMEQUEST480(having 32GB memory), I could not boot dom0 with dom0_mem=31G. But I could boot dom0 with dom0_mem=512M. This is caused by p2m_expose_init(). The below is the boot log. ELILO boot: Uncompressing Linux... done Loading file ..\xen\initrd-2.6.16.33-xen.img-takebe...done Loading file ..\xen\vmlinuz-2.6.16.33-xen-takebe...done Uncompressing... done __ ___ ___ __ _ \ \/ /___ _ __ |___ / / _ \_ _ _ __ ___| |_ __ _| |__ | | ___ \ // _ \ '_ \|_ \| | | |__| | | | '_ \/ __| __/ _` | '_ \| |/ _ \ / \ __/ | | | ___) | |_| |__| |_| | | | \__ \ || (_| | |_) | | __/ /_/\_\___|_| |_| |(_)___/\__,_|_| |_|___/\__\__,_|_.__/|_|\___| http://www.cl.cam.ac.uk/netos/xen University of Cambridge Computer Laboratory Xen version 3.0-unstable (root@) () Thu Jan 4 17:32:37 JST 2007 Latest ChangeSet: Tue Jan 02 16:42:09 2007 -0700 13111:912f8af36878 (XEN) Console output is synchronous. (XEN) Xen command line: BOOT_IMAGE=scsi0:\EFI\redhat\../xen/xen.gz-takebe com1=19200,8n1,0x3f8,48 console=com1 sync_console dom0_mem=31G (XEN) xen image pstart: 0x400, xenheap pend: 0x800 (XEN) Xen patching physical address access by offset: 0x0 (XEN) find_memory: efi_memmap_walk returns max_page=104 (XEN) Before xen_heap_start: f419f380 (XEN) After xen_heap_start: f43ac000 (XEN) Init boot pages: 0x1c0 - 0x400. (XEN) Init boot pages: 0x800 - 0x6a19f000. (XEN) Init boot pages: 0x6b02e270 - 0x6b624010. (XEN) Init boot pages: 0x6b624070 - 0x6b627f59. (XEN) Init boot pages: 0x6b627fcc - 0x6b62b000. (XEN) Init boot pages: 0x6b769c1d - 0x6b796010. (XEN) Init boot pages: 0x6b7966a0 - 0x6d00. (XEN) Init boot pages: 0x1 - 0x8. (XEN) Init boot pages: 0x408000 - 0x41. (XEN) System RAM: 32448MB (33226752kB) (XEN) size of virtual frame_table: 81216kB (XEN) virtual machine to physical table: f3fff7e0 size: 16304kB (XEN) max_page: 0x104 (XEN) allocating frame table/mpt table at mfn 0. (XEN) Domain heap initialised: DMA width 30 bits (XEN) Xen heap: 60MB (61776kB) (XEN) ACPI: RSDP (v002 FUJITS) @ 0x7fc7c000 (XEN) ACPI: XSDT (v001 FUJITS PQ 0x0003 FJ 0x0001) @ 0x7fcbbf28 (XEN) ACPI: FADT (v003 FUJITS PQ 0x0001 FJ 0x0001) @ 0x7fcbba18 (XEN) ACPI: MADT (v001 FUJITS PQ 0x0001 FJ 0x0001) @ 0x7fcbbb10 (XEN) ACPI: SPCR (v001 FUJITS PQ 0x0001 FJ 0x0001) @ 0x7fcbbc18 (XEN) ACPI: SRAT (v001 FUJITS PQ 0x0001 FJ 0x0001) @ 0x7fcbbc68 (XEN) ACPI: SLIT (v001 FUJITS PQ 0x0001 FJ 0x0001) @ 0x7fcbbd78 (XEN) ACPI: SPMI (v001 FUJITS PQ 0x0001 FJ 0x0001) @ 0x7fcbbea8 (XEN) ACPI: WSPT (v001 FUJITS PQ 0x0001 FJ 0x0001) @ 0x7fcbbf00 (XEN) ACPI: DSDT (v002 FUJITS PQ 0x0001 MSFT 0x0202) @ 0x (XEN) Number of logical nodes in system = 1 (XEN) Number of memory chunks in system = 4 (XEN) SAL 3.20: FUJITSU LIMITED PRIMEQUEST version 2.5 (XEN) SAL Platform features: None (XEN) SAL: AP wakeup using external interrupt vector 0xf0 (XEN) No logical to physical processor mapping available (XEN) avail:0x1180c600,
Re: [Xen-ia64-devel] Re: [PATCH][RFC] fix dom0 builder TAKE3
On Thu, Jan 04, 2007 at 05:22:48PM +0900, Akio Takebe wrote:
On our PRIMEQUEST480(having 32GB memory), I could not boot dom0 with
dom0_mem=31G.
But I could boot dom0 with dom0_mem=512M.
This is caused by p2m_expose_init().
The below is the boot log.
Thanks for testing.
Does the atatched patch fix the issue?
--
yamahata
# HG changeset patch
# User [EMAIL PROTECTED]
# Date 1167901217 -32400
# Node ID 9e1ab89735c2b20c14783633609dcdaa2347d7e5
# Parent 3b02c5420099e123c600e1fb745c29b6e2a183eb
fix dom0vp_expose_p2m. It assumes that memory is populated not-spasely.
However with dom0 builder modification this assumption became not-always true.
Make dom0vp_expose_p2m() allow spasely populated memory.
PATCHNAME: spase_memory_dom0vp_expose_p2m
Signed-off-by: Isaku Yamahata [EMAIL PROTECTED]
diff -r 3b02c5420099 -r 9e1ab89735c2 xen/arch/ia64/xen/mm.c
--- a/xen/arch/ia64/xen/mm.cWed Dec 27 18:43:12 2006 +0900
+++ b/xen/arch/ia64/xen/mm.cThu Jan 04 18:00:17 2007 +0900
@@ -1544,8 +1544,7 @@ dom0vp_expose_p2m(struct domain* d,
for (i = 0; i expose_num_pfn / PTRS_PER_PTE + 1; i++) {
assign_pte = lookup_noalloc_domain_pte(d, (assign_start_gpfn + i)
PAGE_SHIFT);
-BUG_ON(assign_pte == NULL);
-if (pte_present(*assign_pte)) {
+if (assign_pte == NULL || pte_present(*assign_pte)) {
continue;
}
if (expose_p2m_page(d, (assign_start_gpfn + i) PAGE_SHIFT,
___
Xen-ia64-devel mailing list
Xen-ia64-devel@lists.xensource.com
http://lists.xensource.com/xen-ia64-devel
Re: [Xen-ia64-devel] Re: [PATCH][RFC] fix dom0 builder TAKE3
On Thu, 2007-01-04 at 18:03 +0900, Isaku Yamahata wrote: # HG changeset patch # User [EMAIL PROTECTED] # Date 1167901217 -32400 # Node ID 9e1ab89735c2b20c14783633609dcdaa2347d7e5 # Parent 3b02c5420099e123c600e1fb745c29b6e2a183eb fix dom0vp_expose_p2m. It assumes that memory is populated not-spasely. However with dom0 builder modification this assumption became not-always true. Make dom0vp_expose_p2m() allow spasely populated memory. PATCHNAME: spase_memory_dom0vp_expose_p2m Applied. Thanks, Alex -- Alex Williamson HP Open Source Linux Org. ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
Re: [Xen-ia64-devel] Re: [PATCH][RFC] fix dom0 builder TAKE3
On Thu, 2007-01-04 at 19:40 +0900, Akio Takebe wrote: Hi, Isaku Thank you for your quick reply. I can boot dom0 with dom0_mem=31G! And I can also boot domU with my patch. Applied. Thanks, Alex -- Alex Williamson HP Open Source Linux Org. ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
[Xen-ia64-devel] Re: [PATCH][RFC] fix dom0 builder TAKE3
On Thu, 2006-12-21 at 18:10 +0900, Isaku Yamahata wrote: On Mon, Oct 16, 2006 at 02:41:40PM -0600, Alex Williamson wrote: Yes, I think we'll need to switch to discontig/sparsemem for the dom0 kernel if the memmory map is going to reflect the bare metal hardware memory layout. Unfortunately, just switching to discontig w/ virtual memmap does not solve the problem I'm seeing. The dom0 kernel reports the correct amount of memory early in bootup. Perhaps the balloon driver is causing this(?) Thanks, I looked into balloon driver and found that it doesn't take care of sparsely populated memory. How about those patches? Hi Isaku, Thanks for continuing to work on this. These patches seem to work fine for me, I booted with a 64GB dom0. Are there any known outstanding issues with these patches (since they were sent as an RFC) or should we add them to the tree? It would certainly be nice to remove the dom0 memory limitations. Thanks, Alex -- Alex Williamson HP Open Source Linux Org. ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
