Hi Alex,
On 08/10/2020 20:52, Alex Bennée wrote:
Julien Grall julien@xen.org writes:
Hi Alex,
On 08/10/2020 11:54, Alex Bennée wrote:
Stefano Stabellini stefano.stabellini@xilinx.com writes:
On Fri, 2 Oct 2020, Alex Bennée wrote:
Hi Julian,
Another data point, this time on real HW:
Xen 4.15-unstable (c/s Wed Sep 30 12:25:05 2020 +0100 git:e680dde6fd) EFI loader
<snip> >> (XEN) >> (XEN) Xen stack trace from sp=00000000002ffcf0: >> (XEN) 00000000002ffd20 000000000020404c 00000000002a5448 0000000000000001 >> (XEN) 00000000002ffd40 f11e576000204150 00000000002ffd50 00000000002c417c >> (XEN) 00000000002b25c0 0000000000000001 00000000002b2620 000080042ffde5d0 >> (XEN) 00000000002ffd90 00000000002bdbe0 000080042ffde5d0 0000000000000001 >> (XEN) 00000000002ddc68 0000000000000000 0000000000000004 00000000ffffffc8 >> (XEN) 00000000002ffdd0 00000000002bf09c 0000000000000004 0000000000000004 >> (XEN) 00000000002b0580 000000000033e430 0101010101010101 0000000000000000 >> (XEN) 00000000002ffdf0 00000000002cbaec 0000000000000004 0000000000000004 >> (XEN) 000000003f8790a0 00000000002001b8 00000000aab35000 00000000aa935000 >> (XEN) 00000000b2273000 0000000000000000 0000000000400000 00000000b22ad018 >> (XEN) 00000000aabe7138 0000000000000001 0000000000000001 8000000000000002 >> (XEN) 0000000000000000 00000000002e1948 00000000b2273000 0000000000009000 >> (XEN) 0000000000000000 0000000000000000 0000000000000000 0000000300000000 >> (XEN) 0000000000000000 00000040ffffffff 00000000ffffffff 0000000000000000 >> (XEN) 0000000000000000 0000000000000000 0000000000000000 0000000000000000 >> (XEN) 0000000000000000 0000000000000000 0000000000000000 0000000000000000 >> (XEN) 0000000000000000 0000000000000000 0000000000000000 0000000000000000 >> (XEN) 0000000000000000 0000000000000000 0000000000000000 0000000000000000 >> (XEN) 0000000000000000 0000000000000000 0000000000000000 0000000000000000 >> (XEN) 0000000000000000 0000000000000000 0000000000000000 0000000000000000 >> (XEN) 0000000000000000 0000000000000000 0000000000000000 0000000000000000 >> (XEN) 0000000000000000 0000000000000000 0000000000000000 0000000000000000 >> (XEN) 0000000000000000 0000000000000000 0000000000000000 0000000000000000 >> (XEN) 0000000000000000 0000000000000000 0000000000000000 0000000000000000 >> (XEN) 0000000000000000 0000000000000000 >> (XEN) Xen call trace: >> (XEN) [<000000000025ed4c>] strlen+0x10/0x84 (PC) >> (XEN) [<00000000002030f8>] dt_device_is_compatible+0x48/0x84 (LR) >> (XEN) [<000000000020404c>] dt_match_node+0x70/0x10c >> (XEN) [<00000000002c417c>] device_init+0x90/0xdc >> (XEN) [<00000000002bdbe0>] iommu_hardware_setup+0x5c/0x188 >> (XEN) [<00000000002bf09c>] iommu_setup+0x30/0x188 >> (XEN) [<00000000002cbaec>] start_xen+0xac4/0xc88 >> (XEN) [<00000000002001b8>] arm64/head.o#primary_switched+0x10/0x30 > > This seems to be the same bug in GRUB noticed by Masami, where GRUB is > adding strings to device tree at runtime without '\0' at the end. Julien > posted a potential (untested) fix for GRUB:
What version of GRUB are you using?
2.04-11 - so The current Debian Testing package with your patch applied. I'd avoided build grub from scratch to avoid screwing up the system but if it's just a drop in .efi binary then I can build from the vanilla tree.
That's understandable. Before switching to GRUB upstream, I would like to understand which compatible is likely not NUL-terminated.
Would you mind to apply this patch in Xen and post the full log?
diff --git a/xen/common/device_tree.c b/xen/common/device_tree.c index e107c6f89f1b..1c88fef4d3af 100644 --- a/xen/common/device_tree.c +++ b/xen/common/device_tree.c @@ -212,11 +212,28 @@ bool_t dt_device_is_compatible(const struct dt_device_node *device, const char *compat) { const char* cp; - u32 cplen, l; + u32 cplen, l, i; + + printk("Check compatible for node %s\n", + device->full_name);
cp = dt_get_property(device, "compatible", &cplen); + if ( cp == NULL ) return 0; + + printk("cplen %u\n", cplen); + for ( i = 0; i < cplen; i++ ) + { + if ( cp[i] == '\0' ) + printk("\n"); + else + printk("%c", cp[i]); + } + + if ( cp[cplen - 1] != '\0') + printk("\n /!\ The compatible property is not NULL terminated\n"); + while ( cplen > 0 ) { if ( dt_compat_cmp(cp, compat) == 0 )
This patch will printk the compatible for each call to dt_device_is_compatible() and print a message if one property is not NUL-terminated.
Cheers,