Re: XEN on R-CAR H3

From: Julien Grall <julien.grall@arm.com>
To: Amit Tomer <amittomer25@gmail.com>, Oleksandr <olekstysh@gmail.com>
Cc: xen-devel@lists.xenproject.org, andrii_chepurnyi@epam.com
Subject: Re: XEN on R-CAR H3
Date: Wed, 20 Feb 2019 20:13:57 +0000	[thread overview]
Message-ID: <06da3bda-93ba-82a8-d155-02224a79bb8a@arm.com> (raw)
In-Reply-To: <CABHD4K_vMN+QRJgxkJjRuZ+_NSGTyXnJC=qvAw5cKGn_nsvV2A@mail.gmail.com>

Hi Amit,

Thank you for the report.

On 2/19/19 4:46 PM, Amit Tomer wrote:
> (XEN) CPU7 MIDR (0x410fd034) does not match boot CPU MIDR (0x411fd073),
> (XEN) disable cpu (see big.LITTLE.txt under docs/).
> (XEN) CPU7 never came online
> (XEN) Failed to bring up CPU 7 (error -5)
> (XEN) Brought up 4 CPUs
> (XEN) P2M: 44-bit IPA with 44-bit PA and 8-bit VMID
> (XEN) P2M: 4 levels with order-0 root, VTCR 0x80043594
> (XEN) I/O virtualisation disabled
> (XEN) build-id: 74f80103afa98953c029eea87d69696bcd5ef69d
> (XEN) alternatives: Patching with alt table 00000000002abba8 -> 00000000002ac1f0
> (XEN) CPU0 will call ARM_SMCCC_ARCH_WORKAROUND_1 on exception entry
> (XEN) CPU2 will call ARM_SMCCC_ARCH_WORKAROUND_1 on exception entry
> (XEN) CPU3 will call ARM_SMCCC_ARCH_WORKAROUND_1 on exception entry
> (XEN) CPU1 will call ARM_SMCCC_ARCH_WORKAROUND_1 on exception entry
> (XEN) *** LOADING DOMAIN 0 ***
> (XEN) Loading Domd0 kernel from boot module @ 000000007a000000
> (XEN) Allocating 1:1 mappings totalling 512MB for dom0:
> (XEN) BANK[0] 0x00000050000000-0x00000070000000 (512MB)
> (XEN) Grant table range: 0x00000048000000-0x00000048040000
> (XEN) Allocating PPI 16 for event channel interrupt
> (XEN) Loading zImage from 000000007a000000 to 0000000050080000-0000000051880000
> (XEN) Loading dom0 DTB to 0x0000000058000000-0x0000000058010a48
> (XEN)
> (XEN) ****************************************
> (XEN) Panic on CPU 0:
> (XEN) Unable to copy the DTB to dom0 memory (left = 68168 bytes)
> (XEN) ****************************************

This is a bit odd. The function copy_to_guest_phys_flush_dcache can
only fail when the P2M entry is invalid or it is not a RAM page.

From the log, it can't even copy the first page. However, this seems 
to belong to the RAM (see BANK[0] message). Would you mind to apply the
following patch and send the log?

diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
index d9836779d1..08b9cd2c44 100644
--- a/xen/arch/arm/domain_build.c
+++ b/xen/arch/arm/domain_build.c
@@ -1805,6 +1805,8 @@ static void __init dtb_load(struct kernel_info *kinfo)
     printk("Loading dom0 DTB to 0x%"PRIpaddr"-0x%"PRIpaddr"\n",
            kinfo->dtb_paddr, kinfo->dtb_paddr + fdt_totalsize(kinfo->fdt));
 
+    dump_p2m_lookup(kinfo->d, kinfo->dtb_paddr);
+
     left = copy_to_guest_phys_flush_dcache(kinfo->d, kinfo->dtb_paddr,
                                            kinfo->fdt,
                                            fdt_totalsize(kinfo->fdt));

Cheers,

-- 
Julien Grall

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
