From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from list by lists.gnu.org with archive (Exim 4.71) id 1aZiJA-0003uz-5x for mharc-grub-devel@gnu.org; Sat, 27 Feb 2016 12:05:32 -0500 Received: from eggs.gnu.org ([2001:4830:134:3::10]:39835) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aZiJ6-0003ue-T2 for grub-devel@gnu.org; Sat, 27 Feb 2016 12:05:29 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aZiJ3-0004Zd-LZ for grub-devel@gnu.org; Sat, 27 Feb 2016 12:05:28 -0500 Received: from mail-lb0-x233.google.com ([2a00:1450:4010:c04::233]:36546) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aZiJ3-0004Yy-8z for grub-devel@gnu.org; Sat, 27 Feb 2016 12:05:25 -0500 Received: by mail-lb0-x233.google.com with SMTP id x1so60990891lbj.3 for ; Sat, 27 Feb 2016 09:05:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=wL0roeNjwfaHgwj+p2ougdXApNtjmjCJveUTYp3xiqM=; b=MF8Nu026UxEH8Htn1pojmY7z7r5/ytc/yevLuuBJ1BM4UsyLyDO0RAOy8vy6fAvthF b/aYfqZJKZCcajQB6251jaJOvAgufxyZLhXZhHJidUAZLmnUmU5U5UI0euQVt1KTlGYD yMUg84rP5G7vahp8P0qEAPE3+6jXLTz/lvT6cFvLjuUFHbpTnN++wMKMHzMJAZVvZ7NN C+zl5f1jkVLtcD/4REeTikYTPTg5QqkZFU+A0fuaKahXqhPrsove1JUbvthIkQWSIdnt 4VkI9x4Gi73nIOZnjK30r21skdBUEdrL/gYjbs8dfPNI7Un8LfU8qbJ4tUBmxd4UucrY LJGw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=wL0roeNjwfaHgwj+p2ougdXApNtjmjCJveUTYp3xiqM=; b=mzaJ3G/+dd/WX3E+htChyf+BrlSKjqghS7ZZxUCNvmHWaDGgASnYnVp/gfagrKcPch d1Zije8Omk1lcye4g/u9dap1Cj6X90j1/zspjdsMApfb1fS/MwbmidvOydXU9SYmScEe xNZ+jNKnUI07iZCDaB6wXKAOc8GszX2NzsWTfuZ7J+XJH/6QIMhD9Z+ecb2wSIBjh0dp GYk321v7RBVk25dQr9JYDoYUfUATboxOlRDZMtCs31BREWOq+G4iZSahztXfww5dM2Eb x+baug4BGiXW8i88DK+ETu3ThPnIXeWUPYCdSE3gasNgDyqVwCDSPJb7NHeQGvBfKLje 3qMw== X-Gm-Message-State: AD7BkJLvPVcxYMjja0pSVxPJXrydAeWUfD5EIApWnUsnbf+3a+IKljyFoGkbgeRh5Lkttw== X-Received: by 10.112.91.202 with SMTP id cg10mr2638579lbb.142.1456592724314; Sat, 27 Feb 2016 09:05:24 -0800 (PST) Received: from [192.168.1.41] (ppp109-252-76-159.pppoe.spdop.ru. [109.252.76.159]) by smtp.gmail.com with ESMTPSA id i66sm2593271lfg.4.2016.02.27.09.05.22 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 27 Feb 2016 09:05:23 -0800 (PST) Subject: Re: [PATCH] arm64: xen_boot: Fix xen boot using Grub on AARCH64 To: The development of GNU GRUB , Ian Campbell References: <1455899332-9054-1-git-send-email-julien.grall@linaro.org> <1456221631.6225.119.camel@citrix.com> From: Andrei Borzenkov X-Enigmail-Draft-Status: N1110 Message-ID: <56D1D752.7050200@gmail.com> Date: Sat, 27 Feb 2016 20:05:22 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2a00:1450:4010:c04::233 Cc: Vladimir Serbinenko , Julien Grall , xen-devel , stefano.stabellini@citrix.com, Steve Capper 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: Sat, 27 Feb 2016 17:05:30 -0000 23.02.2016 17:16, Fu Wei пишет: > Hi Ian > > On 23 February 2016 at 18:00, Ian Campbell wrote: >> On Mon, 2016-02-22 at 17:29 +0800, Fu Wei wrote: >>> Hi Julien, >>> >>> 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. >>>> --- >>>> grub-core/loader/arm64/xen_boot.c | 2 +- >>>> 1 file changed, 1 insertion(+), 1 deletion(-) >>>> >>>> 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) >>>> grub_fdt_add_subnode (xen_boot_fdt, chosen_node, module_name); >>>> >>>> retval = grub_fdt_set_prop (xen_boot_fdt, module_node, "compatible", >>>> - MODULE_CUSTOM_COMPATIBLE, >>>> sizeof(MODULE_CUSTOM_COMPATIBLE) - 1); >>>> + MODULE_CUSTOM_COMPATIBLE, >>>> sizeof(MODULE_CUSTOM_COMPATIBLE)); >>>> if (retval) >>>> return grub_error (GRUB_ERR_IO, "failed to update FDT"); >>>> >>>> -- >>>> 1.9.1 >>> >>> I have tested it. yes, xen will crash without this patch. >>> Tested-by: Fu Wei >>> >>> BTW, since Vladimir has simplified the xen boot code , and Now Xen >>> distinguishes modules by order. >>> ------ >>> menuentry 'Foundation Model Xen test with initramfs' { >>> xen_hypervisor /xen -- no-bootscrub console=dtuart conswitch=x >>> dtuart=serial0 dom0_mem=512M dom0_max_vcpus=2 >>> xen_module /dom0_kernel_Image console=hvc0 root=/dev/ram0 ro >>> xen_module /dom0_initramfs.cpio >>> xen_module /xsm >>> devicetree /fvp-base-gicv2-psci.dtb >>> } >>> ----- >>> >>> Maybe we should update doc to coordinate with this change. >>> >>> 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? >> > > From the test result, it seems that the latest xen can NOT > automatically probe XSM module, even we load xsm as the third module. > > the test branch is master branch. Please correct me if I tested it in wrong way. > That's exactly what code looks like. I.e. XSM is recognized only if bootloader provided xen,xsm-policy compatible property. OTOH looking at xsm_dt_policy_init(), XSM module has defined magic and multiboot version actually detects module type based on this magic. So I think it makes sense to extend process_multiboot_node() to check for XSM magic in case of unknown modules. This will make ARM behavior compatible with x86. Otherwise we simply won't be able to load XSM on ARM at all, given current implementation in GRUB.