[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH 1/2] xen/efi: Restrict check for DT boot modules on EFI boot

  • To: Stefano Stabellini <sstabellini@xxxxxxxxxx>
  • From: Jan Beulich <jbeulich@xxxxxxxx>
  • Date: Thu, 16 Sep 2021 08:45:26 +0200
  • Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=suse.com; dmarc=pass action=none header.from=suse.com; dkim=pass header.d=suse.com; arc=none
  • Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=ljQFwkl0043Igxc8fvmVI209+Fmz0veBvqBLCjOpVCQ=; b=P3WQ5/nvGbwHDYZUPcCYib45heuocqLQON07BuoZzBlqlrxBOQL/+s6CdKXpPHKfpUpfv9FwHsz6C0LbDGskKfnAjfOKdes8olaEfb3bMpWK+9VQsM/pX0j2wA3JyJvcgN6QgXSAX8mZ7hNMz5VOLMdaAhKXbeVLlZaXQV3C3llP3dRl2ipWChOuXH7COC4n5qrdXh+rYKEdSF0mziSgW1KOL4gZeyf7+Gy9biABYeg4ddrCjk9PF39FCRK21YLl9H/dHlAS07OqpIoaNq+m7IL7BkvCmTqG8BOqoHv4YxuWHg73M5gqjy6xbgnNdCqknevjEWMVOOllEO2I16wGeQ==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=hzcFbFT0WOJa6GjVF+X3UomqVDsfO3tNTTMM1TdYdL1RyfHrzs6wdM1G47eWpmvzTuHdUxofRwp4KB8fQ59Fm7zzVeZ2HmYjsyS3HS/LMWJYuW1BcSVVaqfSD6H4BANx9BUe7VJq+YY/aaEefrwYG3RCCZNJH8lJlnoIZz+NMluR5Mq8cp8uY7Ozj7YP2oZgTQfXtm18928xgLpZ/5CTgEYw9KnD58bUahAOBU3QU8F3mNhj5ow2nL2TpILEI4O5t/zlnwdrKcNN35y4sJGtvTZPJd0PiHb9Vq1+EuntRxvtm9u2R44leBALfQCWQZ05VCcGcfpnD2t3+gVtA6FDHg==
  • Authentication-results: arm.com; dkim=none (message not signed) header.d=none;arm.com; dmarc=none action=none header.from=suse.com;
  • Cc: xen-devel@xxxxxxxxxxxxxxxxxxxx, bertrand.marquis@xxxxxxx, wei.chen@xxxxxxx, Julien Grall <julien@xxxxxxx>, Volodymyr Babchuk <Volodymyr_Babchuk@xxxxxxxx>, Luca Fancellu <luca.fancellu@xxxxxxx>
  • Delivery-date: Thu, 16 Sep 2021 06:45:41 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

On 16.09.2021 02:16, Stefano Stabellini wrote:
> So I am thinking that we have no choice but introducing a new property
> to tell us whether we should or should not load xen.cfg when
> multiboot,modules are present.
> Taking inspiration from HyperLaunch, it could be a new node:
> chosen {
>     cfg {
>         compatible = "xen,uefi-config", "multiboot,module";
>         uefi,binary = "xen.cfg";
>     };
> };
> In efi_arch_use_config_file we would check if there are any nodes
> compatible with "multiboot,module". If there are none, it returns true.
> If there are any, and one of them is also compatible "xen,uefi-config",
> then efi_arch_use_config_file returns true and also the specified
> configuration filename.
> If there are nodes compatible to "multiboot,module" but none of them is
> compatible to "module,uefi-config", then efi_arch_use_config_file
> returns false. We use the device tree only.
> I think that would be clearer and more consistent from a specification
> perspective, but it requires one change in common code:
> efi_arch_use_config_file would not just return bool but it would also
> return a filename if found (it could be a pointer parameter to the
> function).
> Otherwise, we could add a simple property like the following, without a
> specific value and without a filename:
> chosen {
>     xen,uefi-config;
> };
> The presence of xen,uefi-config could mean that Xen should go through
> the usual guessing game to figure out the right cfg file to load. This
> would not require any common code changes because
> efi_arch_use_config_file could simply return bool as it does today.
> My preference is the xen,uefi-config compatible node, but I think the
> property would also work.
> Jan, do you have an opinion on whether efi_arch_use_config_file has to
> stay as it is today, or would you be open to the possibility of making
> efi_arch_use_config_file return a filename too?

I see no issue with making such a change; my preference would be an
altered return type, provided all present cases can be expressed
alongside the new one you need.




Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.