|
|
|
|
|
|
|
|
|
|
xen-devel
Re: [Xen-devel] Xen dom0 crash: "d0:v0: unhandled page fault (ec=0000)"
> >> http://pastebin.com/3m0DpDdW - 2.6.32.24-gd0054d6-dirty - broken
.. snip..
> The way is this is supposed to work is:
>
> 1. Xen gives the domain N pages
> 2. There's an E820 which describes M pages (M > N)
> 3. The kernel traverses the existing E820 and finds holes and adds
> the memory to a new E820_RAM region beyond M
> 4. Set up P2M for pages up to N
> 5. When the kernel maps all "RAM", the region from N-M is not
> present, and has no valid P2M mapping; in that case, xen_make_pte
> will return a non-present pte.
Right, and somehow his machine/kernel is not doing this. His 'N' ends up being
'M' so
the region N-M is added to the "RAM", and xen_make_pte I _think_ returns a
non-present pte
(or maybe it does present a present pte?) In the previous kernel (2.6.32.18), it
does exactly what you described.
Take a look at his http://pastebin.com/3m0DpDdW
[ 0.000000] Xen: 0000000000000000 - 000000000009e000 (usable)
[ 0.000000] Xen: 0000000000100000 - 000000002f000000 (usable)
[ 0.000000] Xen: 00000000bf699000 - 00000000bf6af000 (reserved)
[ 0.000000] Xen: 00000000bf6af000 - 00000000bf6ce000 (ACPI data)
[ 0.000000] Xen: 00000000bf6ce000 - 00000000c0000000 (reserved)
[ 0.000000] Xen: 00000000e0000000 - 00000000f0000000 (reserved)
[ 0.000000] Xen: 00000000fe000000 - 0000000100000000 (reserved)
[ 0.000000] Xen: 0000000240000000 - 00000002d0699000 (usable)
He passes in dom0_mem=752M flag, so it should stop right at pfn 2f0000,
but it continues on with 0x2d0699.
>
> The important part of making XEN EXTRA E820_RAM is that the kernel will
> allocate page structures for them, even if the pages are absent. Making
> it RESERVED will suppress that and make the exercise pointless.
<nods> Happens in 2.6.32.18, but not 2.6.32.24 with his kernel. That region ends
up being allocated.
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
|
|
|
|