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

Re: [PATCH v8] Preserve the EFI System Resource Table for dom0


  • To: Demi Marie Obenour <demi@xxxxxxxxxxxxxxxxxxxxxx>
  • From: Jan Beulich <jbeulich@xxxxxxxx>
  • Date: Tue, 5 Jul 2022 12:56:56 +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:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=9YsDQetN1expk9M0MJKOywrzAPpHOWaDrCoMJc3+6nU=; b=j3lB8+6y4vpaTKP47RelYqZ7RR+9ZQzAbfH8TfwE7WtLCjhp8dritWME5iX3TP62Hzux5D79tPNwK3D4ZsxN83b1d5iMH9zvjhxI4Dq2uGw9iZPvjxxXkSb5wj1aJat4aZ2v+6OLOf6XmubAVkXIrVQhjvQTR+fJI+BiPcdyM9yF++xWtF/rAtufzRq+W1+Xx7gt97ffoH9cQcaSmot5Bdq5xYFugupA0/86iSQq16sRgYR5BtGFqOFK0n1Mc42wbLHpgECU82v5Y372acAKA5BRs/vJ5MQTZWWXKN9zzIjHtrGYcJkXTo4G0D9zz1TNsvn6YKhsJam2VsW4gEUHQA==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=GsvTRT4lemodHtUSENUsxZKxgysVU9BW1qdQnwgfk4XrLOxiKL7TT6RCpEdLwTf1OadloSRQkkkrAs0w3i0IeEfrbTeXPh8jx9b05LZR32vCbJ4Y8DDIZKTRPRAuz0YAprOiFNg8ESbAxcW4kohPgO3yIsuPtA/0X5HWdskhQXK4lrHficFT/CTd6or4Jb9u/+PhjNG9Hfvxuom1L0b7QEcZm7V7REyMZHWq8OYCm1lQQZZjMwuXB1uA6G6SkXDkPfhhCZZ+oEyhWjOlenaxSsVOFXvrwhwdGoWyed4Nka6w1a7aNGcuwaKWewE6G9A+Ko2zVxkzg77gxfWNqROj+Q==
  • Authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=suse.com;
  • Cc: xen-devel@xxxxxxxxxxxxxxxxxxxx
  • Delivery-date: Tue, 05 Jul 2022 10:57:24 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

On 24.06.2022 20:17, Demi Marie Obenour wrote:
> The EFI System Resource Table (ESRT) is necessary for fwupd to identify
> firmware updates to install.  According to the UEFI specification §23.4,
> the ESRT shall be stored in memory of type EfiBootServicesData.  However,
> memory of type EfiBootServicesData is considered general-purpose memory
> by Xen, so the ESRT needs to be moved somewhere where Xen will not
> overwrite it.  Copy the ESRT to memory of type EfiRuntimeServicesData,
> which Xen will not reuse.  dom0 can use the ESRT if (and only if) it is
> in memory of type EfiRuntimeServicesData.
> 
> Earlier versions of this patch reserved the memory in which the ESRT was
> located.  This created awkward alignment problems, and required either
> splitting the E820 table or wasting memory.  It also would have required
> a new platform op for dom0 to use to indicate if the ESRT is reserved.
> By copying the ESRT into EfiRuntimeServicesData memory, the E820 table
> does not need to be modified, and dom0 can just check the type of the
> memory region containing the ESRT.  The copy is only done if the ESRT is
> not already in EfiRuntimeServicesData memory, avoiding memory leaks on
> repeated kexec.
> 
> See https://lore.kernel.org/xen-devel/20200818184018.GN1679@mail-itl/T/
> for details.
> 
> Signed-off-by: Demi Marie Obenour <demi@xxxxxxxxxxxxxxxxxxxxxx>

Reviewed-by: Jan Beulich <jbeulich@xxxxxxxx>
with one further adjustment:

> @@ -1051,6 +1110,70 @@ static void __init 
> efi_set_gop_mode(EFI_GRAPHICS_OUTPUT_PROTOCOL *gop, UINTN gop
>  #define INVALID_VIRTUAL_ADDRESS (0xBAAADUL << \
>                                   (EFI_PAGE_SHIFT + BITS_PER_LONG - 32))
>  
> +static void __init efi_relocate_esrt(EFI_SYSTEM_TABLE *SystemTable)
> +{
> +    EFI_STATUS status;
> +    UINTN info_size = 0, map_key, mdesc_size;
> +    void *memory_map = NULL;
> +    UINT32 ver;
> +    unsigned int i;
> +
> +    for ( ; ; ) {

In reply to v7 I said:

"Nit: Style:

    for ( ; ; )
    {
"

which you've dealt with just partly. This time I'll take care of this
while committing.

Also for future patches please remember that having brief per-revision
change notes are quite helpful to reviewers.

Jan



 


Rackspace

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