Re: [Xen-devel] dom0 pvops boot crash on very ordinary Dell R310

[Ian Campbell <Ian.Campbell@xxxxxxxxxx>]

On Wed, 2010-10-27 at 10:15 +0100, Ian Campbell wrote:
> 
> This code path already indirects through
> "x86_init.mpparse.find_smp_config" but I can't see where Xen overrides
> that hook, if indeed that would be the correct thing to do. I suspect
> it is right and that this hook should be a NOP under PV Xen.

My suspicion was wrong, but IanJ gave me access to the machine so I know
have some clue what's going on.

Xen sees:
        (XEN) Xen-e820 RAM map:
        (XEN)  0000000000000000 - 000000000009e000 (usable)
        (XEN)  0000000000100000 - 00000000bf699000 (usable)
        (XEN)  00000000bf699000 - 00000000bf6af000 (reserved)
        (XEN)  00000000bf6af000 - 00000000bf6ce000 (ACPI data)
        (XEN)  00000000bf6ce000 - 00000000c0000000 (reserved)
        (XEN)  00000000e0000000 - 00000000f0000000 (reserved)
        (XEN)  00000000fe000000 - 0000000100000000 (reserved)
        (XEN)  0000000100000000 - 0000000240000000 (usable)

Dom0 then sees:
        BIOS-provided physical RAM map:
         Xen: 0000000000000000 - 000000000009e000 (usable)
         Xen: 00000000000a0000 - 0000000000100000 (reserved)
         Xen: 0000000000100000 - 0000000020000000 (usable)
         Xen: 00000000bf699000 - 00000000bf6af000 (reserved)
         Xen: 00000000bf6af000 - 00000000bf6ce000 (ACPI data)
         Xen: 00000000bf6ce000 - 00000000c0000000 (reserved)
         Xen: 00000000e0000000 - 00000000f0000000 (reserved)
         Xen: 00000000fe000000 - 0000000100000000 (reserved)
         Xen: 0000000240000000 - 00000002df69b000 (usable)

which is similar but not quite identical. In particular just before dom0
prints its map we see:
        xen_release_chunk: looking at area pfn 9e-a0: 2 pages freed
        released 2 pages of unused memory

With a bit of debugging in the mmpparse code we see:
        default_find_smp_config
        smp_scan_config base 0x0 at c0000000
        smp_scan_config base 0x9fc00 at c009fc00
        (XEN) d0:v0: unhandled page fault (ec=0000)

IOW we are faulting on precisely one of the PFNs which we earlier
released. We released these because of a hole in the e820 between
0xa0000-0x100000 which dom0 apparently manufactured. 

IIRC in a PV domU we reserve some of the legacy address space to stop
old ISA drivers etc from getting at it. I suspect this is wrong for a
dom0 where we want the e820 to be more or less unmolested. I'll track
down the code in question and see if removing it for dom0 helps.

Ian.



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