Hi Amit,
On 2/21/19 6:15 PM, Amit Tomer wrote:
Hi,
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));
Please find the logs after applying this patch:
(XEN) CPU2 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-0x0000000058010a44
(XEN) dom0 IPA 0x0000000058000000
(XEN) P2M @ 000000080c23dc90 mfn:0x73ff5e
(XEN) 0TH[0x0] = 0x008000073ff5c7ff
(XEN) 1ST[0x1] = 0x008000073ff3d7ff
(XEN) 2ND[0xc0] = 0x02c00000580006fd
Thank you for giving a try! The p2m type for the entry is p2m_mmio_direct_c.
This confirms the finding on the other threads. I would suggest you to
remove the reserved-memory nodes until Xen gain knowledge of reserved
memory.
FIY, Stefano has posted a patch series yesterday aiming to solve this
issues.
Cheers,
--
Julien Grall
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
