Re: [Xen-ia64-devel] [PATCH] Use saner dom0 memory and vcpu defaults, don't panic on over-allocation

[Jarod Wilson <jwilson@xxxxxxxxxx>]

Alex Williamson wrote:
> On Fri, 2007-08-03 at 11:09 -0400, Jarod Wilson wrote:
>>>>> Indeed, on my 16GB system, only 8MB less from the v2 incantation, and
>>>>> the dom0_mem=0 option does properly allocate all available memory to
>>>>> dom0. I'm quite happy with this version if everyone else is...
>>>> Eep! I retract my happiness... Seems with all memory allocated like
>>>> this, I can't get a guest to actually boot. I get this when I try to
>>>> bring one up via xm create:
> 
>    It's still not completely happy on my 96G system.  If I specify
> dom0_mem=0, dom0 fails to startup.

Damn, I need a 96G system... ;)

> It's incredibly close to the right
> value though.  The max calculated memory is:
> 
> (XEN) Maximum permitted dom0 size: 97841MB
> 
> This fails just before launching dom0 with this:
> 
> (XEN) Domain0 EFI passthrough: ACPI 2.0=0x3fdda000 SMBIOS=0x3e52a000
> (XEN) assign_new_domain_page: Can't alloc!!!! Aaaargh!
> (XEN) 
> (XEN) ****************************************
> (XEN) Panic on CPU 0:
> (XEN) assign_new_domain0_page: can't allocate page for 
> dom0****************************************
> 
> If I reduce this slightly and boot with dom0_mem=97840MB, dom0 starts to
> boot, then hits this:
> 
> CPU 1: synchronized ITC with CPU 0 (last diff -2 cycles, maxerr 154 cycles)
> CPU 2: synchronized ITC with CPU 0 (last diff -8 cycles, maxerr 159 cycles)
> CPU 3: synchronized ITC with CPU 0 (last diff -7 cycles, maxerr 159 cycles)
> Brought up 4 CPUs
> Total of 4 processors activated (12753.30 BogoMIPS).
> migration_cost=11839
> (XEN) mm.c:520:d0 Warning: UC to WB for mpaddr=3e52a010
> DMI 2.3 present.
> NET: Registered protocol family 16
> ACPI: bus type pci registered
> ACPI: Interpreter enabled
> ACPI: Using IOSAPIC for interrupt routing
> ACPI: PCI Root Bridge [L000] (0000:00)
> (XEN) __assign_domain_page:871 WARNING can't assign page domain 
> 0xf000000007c18080 id 0
> (XEN)   already assigned pte_val 0x6400000000000000
> (XEN)   mpaddr 0x00000800bc000000 physaddr 0x00000800bc000000 flags 0x2
> (XEN) __assign_domain_page:871 WARNING can't assign page domain 
> 0xf000000007c18080 id 0
> (XEN)   already assigned pte_val 0xf000000000000000
> (XEN)   mpaddr 0x00000800bc004000 physaddr 0x00000800bc004000 flags 0x2
> (XEN) __assign_domain_page:871 WARNING can't assign page domain 
> 0xf000000007c18080 id 0
> (XEN)   already assigned pte_val 0xf000ff54f0000000
> (XEN)   mpaddr 0x00000800bc008000 physaddr 0x00000800bc008000 flags 0x2
> ...
> 
> To get it to boot all the way to userspace, I had to reduce dom0's
> memory a full 16MB further, down to dom0_mem=97824M.  Each few MB more
> kept for Xen allowed the boot to enumerate another PCI root bridge.  I
> suspect it's the ioremaps going on there that are eating up free heap
> pages.  Maybe this also suggests that xen doesn't really know how much
> dynamic memory it might take to boot dom0 all the way.  Thanks,

I wonder if this is at all similar to the reason for the fudge-factor
inclusion in the x86 code that was originally in here... Any suggestions
for a remedy? Just heist some of those x86 bits again? :)


-- 
Jarod Wilson
jwilson@xxxxxxxxxx

signature.asc
Description: OpenPGP digital signature

_______________________________________________
Xen-ia64-devel mailing list
Xen-ia64-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-ia64-devel