From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from list by lists.gnu.org with archive (Exim 4.71) id 1aY9lq-0006Br-Dz for mharc-grub-devel@gnu.org; Tue, 23 Feb 2016 05:00:42 -0500 Received: from eggs.gnu.org ([2001:4830:134:3::10]:40251) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aY9lo-0006Ae-9Z for grub-devel@gnu.org; Tue, 23 Feb 2016 05:00:41 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aY9lk-0004HN-Mw for grub-devel@gnu.org; Tue, 23 Feb 2016 05:00:40 -0500 Received: from smtp02.citrix.com ([66.165.176.63]:30162) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aY9lk-0004HB-Hf for grub-devel@gnu.org; Tue, 23 Feb 2016 05:00:36 -0500 X-IronPort-AV: E=Sophos;i="5.22,488,1449532800"; d="scan'208";a="340170106" Message-ID: <1456221631.6225.119.camel@citrix.com> Subject: Re: [PATCH] arm64: xen_boot: Fix xen boot using Grub on AARCH64 From: Ian Campbell To: Fu Wei , Julien Grall Date: Tue, 23 Feb 2016 10:00:31 +0000 In-Reply-To: References: <1455899332-9054-1-git-send-email-julien.grall@linaro.org> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.18.2-1 MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable X-DLP: MIA1 X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 66.165.176.63 Cc: The development of GNU GRUB , Vladimir Serbinenko , Steve Capper , stefano.stabellini@citrix.com, xen-devel X-BeenThere: grub-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: The development of GNU GRUB List-Id: The development of GNU GRUB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Feb 2016 10:00:41 -0000 On Mon, 2016-02-22 at 17:29 +0800, Fu Wei wrote: > Hi Julien, >=20 > On 20 February 2016 at 00:28, Julien Grall > wrote: > > Xen is currently crashing because of malformed compatible property for > > the boot module. This is because the property string is not > > null-terminated as requested by the ePAR spec. > > --- > > =C2=A0grub-core/loader/arm64/xen_boot.c | 2 +- > > =C2=A01 file changed, 1 insertion(+), 1 deletion(-) > >=20 > > diff --git a/grub-core/loader/arm64/xen_boot.c b/grub- > > core/loader/arm64/xen_boot.c > > index a914eb8..8ae43d7 100644 > > --- a/grub-core/loader/arm64/xen_boot.c > > +++ b/grub-core/loader/arm64/xen_boot.c > > @@ -156,7 +156,7 @@ prepare_xen_module_params (struct xen_boot_binary > > *module, void *xen_boot_fdt) > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0grub_fdt_add_subnode (xen_boo= t_fdt, chosen_node, module_name); > >=20 > > =C2=A0=C2=A0=C2=A0retval =3D grub_fdt_set_prop (xen_boot_fdt, module_no= de, "compatible", > > -=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0MODULE_CUSTOM_COMPATIBLE, > > sizeof(MODULE_CUSTOM_COMPATIBLE) - 1); > > +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0MODULE_CUSTOM_COMPATIBLE, > > sizeof(MODULE_CUSTOM_COMPATIBLE)); > > =C2=A0=C2=A0=C2=A0if (retval) > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0return grub_error (GRUB_ERR_IO, "failed t= o update FDT"); > >=20 > > -- > > 1.9.1 >=20 > I have tested it. yes, xen will crash without this patch. > Tested-by: Fu Wei >=20 > BTW, since Vladimir has simplified the xen boot code , and Now Xen > distinguishes modules by order. > ------ > menuentry 'Foundation Model Xen test with initramfs' { > =C2=A0=C2=A0=C2=A0=C2=A0xen_hypervisor /xen -- no-bootscrub console=3Ddtu= art conswitch=3Dx > dtuart=3Dserial0 dom0_mem=3D512M dom0_max_vcpus=3D2 > =C2=A0=C2=A0=C2=A0=C2=A0xen_module /dom0_kernel_Image console=3Dhvc0 root= =3D/dev/ram0 ro > =C2=A0=C2=A0=C2=A0=C2=A0xen_module /dom0_initramfs.cpio > =C2=A0=C2=A0=C2=A0=C2=A0xen_module /xsm > =C2=A0=C2=A0=C2=A0=C2=A0devicetree /fvp-base-gicv2-psci.dtb > } > ----- >=20 > Maybe we should update doc to=C2=A0=C2=A0coordinate with this change. >=20 > And another problem is: How does XEN identify XSM? > Test with the config file above, I got "(XEN) MODULE[3]: > 00000008fabb4000 - 00000008fabb65e7 Unknown" I must confess when Vlad proposed this change I thought Xen was able to automatically probe for whether a module was an XSM module. Perhaps it is either broken or that functionality never existed to start with? Ian.