This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Home Products Support Community News


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

To: Ian Jackson <Ian.Jackson@xxxxxxxxxxxxx>
Subject: Re: [Xen-devel] dom0 pvops boot crash on very ordinary Dell R310
From: Ian Campbell <Ian.Campbell@xxxxxxxxxx>
Date: Wed, 27 Oct 2010 14:18:32 +0100
Cc: Jeremy Fitzhardinge <Jeremy.Fitzhardinge@xxxxxxxxxx>, "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>
Delivery-date: Wed, 27 Oct 2010 06:19:52 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <1288170930.8361.163.camel@xxxxxxxxxxxxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
Organization: Citrix Systems, Inc.
References: <19654.64100.877881.133331@xxxxxxxxxxxxxxxxxxxxxxxx> <1288170930.8361.163.camel@xxxxxxxxxxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
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:
        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.


Xen-devel mailing list