From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from NAM10-DM6-obe.outbound.protection.outlook.com (NAM10-DM6-obe.outbound.protection.outlook.com [40.107.93.72]) by mx.groups.io with SMTP id smtpd.web09.1967.1626888376788960062 for ; Wed, 21 Jul 2021 10:26:17 -0700 Authentication-Results: mx.groups.io; dkim=pass header.i=@nvidia.com header.s=selector2 header.b=nIjbTmuj; spf=permerror, err=parse error for token &{10 18 %{i}._ip.%{h}._ehlo.%{d}._spf.vali.email}: invalid domain name (domain: nvidia.com, ip: 40.107.93.72, mailfrom: jbrasen@nvidia.com) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Xl6ADzu1Se2ZJTtCb3LEAFlB5n9DiossVStKEADgM9yXme4++w1SSLnKa4Apm8aPII7eQupzugoc9khwLfFzPp6jMw97S0bw9Da5CcU6tnBU1k0ovjLGNg8qxwLIIBAGHRM3wTDPP4iw/wQO3E90TBF//SyMg3TaqE08FixUwgRqs5SSPN6ncSKozasU018LBleG8dHzF4HMwxEp6sEnZ1hjcCSdot+FSGhRpnYO/Rj85Wgi99SMyJ4WBu0lJHJxjK14V5ndCUYT5lqwqn+AWMxQPagjvqksAZ6RX2/tM7hg0+pcnQFprQyVRfHT+RF5wc06vgW8WQHimZWHNqi4kQ== 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-SenderADCheck; bh=8GTRebyfajitl1F3YvdI940WFossQAP78/W/ksWJWrw=; b=R0SAxPaEmoJ76zvs0lK6fSZsgHKEJYjVqEGivV9jRDDTfuAe2Ut1YzLxK/gnXnnsgH2conhpoHJ7pRITYPsb3yCo03Z9aOAUySnCuQ7pcqndaN5f46ZRoca3N1XSMKDVMMZDA09r+i08y8Q2bBMaS3I8QUIl4NwujRijU8PDP7Lgi5rHCfKivCpzUlHCn1326llfkGd/CtnquQzZxQs4qdOrYTV6W5WIzvBX1XqxKbfpzimrLJo8Np355RAfvjK8TmBaU8/N7xbGcLOj98lpPhq8KKHl7AEYPnyfxRc4HQadvvnYyncc38csmXxXzKkXbtAccmTG8sK/tMmS/aResg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=nvidia.com; dmarc=pass action=none header.from=nvidia.com; dkim=pass header.d=nvidia.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=Nvidia.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=8GTRebyfajitl1F3YvdI940WFossQAP78/W/ksWJWrw=; b=nIjbTmujz4piNUfPMSgTEDPVtL4mNgGY/gmi/QlEUP47tNJxVwi4UB2Vtqr8lCXkH3ksajsqq7P7pAtOIIgtgPoxNvxJI3qByNtnYtq2qkyhw8pUWp09YhaYWxyDdVWdbWVVhadp6xF4FUajNOM6FF+anXRFs7OwbssjABDWklau6dHsfUbTRHt+TXfaZIJbdO+Jwspy9IZM4FopFJkwKeWtrISs9EGQq1I9lUpsGNin4fl+IDb5cDbnqSDn0w3RetNx2Nm6a756ky01jTGpaAQNmDZ746otxbUwb41LhtPeLAmksbSzZ3hv7Ag1iSbQbRwTmC6FxdLlYffTHM35Lg== Received: from DM6PR12MB3340.namprd12.prod.outlook.com (2603:10b6:5:3d::24) by DM6PR12MB4059.namprd12.prod.outlook.com (2603:10b6:5:215::14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4331.23; Wed, 21 Jul 2021 17:26:15 +0000 Received: from DM6PR12MB3340.namprd12.prod.outlook.com ([fe80::6476:8298:560:3950]) by DM6PR12MB3340.namprd12.prod.outlook.com ([fe80::6476:8298:560:3950%2]) with mapi id 15.20.4352.025; Wed, 21 Jul 2021 17:26:15 +0000 From: "Jeff Brasen" To: "Kinney, Michael D" , Ard Biesheuvel CC: "devel@edk2.groups.io" , "ardb+tianocore@kernel.org" , "Justen, Jordan L" , "gaoliming@byosoft.com.cn" , "Liu, Zhiguang" , Samer El-Haj-Mahmoud Subject: Re: [edk2-devel] [PATCH 1/1] MdePkg: add definition of LINUX_EFI_INITRD_MEDIA_GUID Thread-Topic: [edk2-devel] [PATCH 1/1] MdePkg: add definition of LINUX_EFI_INITRD_MEDIA_GUID Thread-Index: AQHXeaRpTUNd1pxiZkq9I+jwTkn0pKtEpekAgAAGJdqAANdngIAAL9cAgAAPsQCABlorCYABfHMAgAAIFCQ= Date: Wed, 21 Jul 2021 17:26:15 +0000 Message-ID: References: , , In-Reply-To: Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: intel.com; dkim=none (message not signed) header.d=none;intel.com; dmarc=none action=none header.from=nvidia.com; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 70d1cdb3-4c72-4afe-ba57-08d94c6ca4ba x-ms-traffictypediagnostic: DM6PR12MB4059: x-microsoft-antispam-prvs: x-ms-exchange-transport-forked: True x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: Mzx27KyJz3uQtuAj1AAOh56fRP1l7uZJlTXrztxi5psyOozKxs/t8Pr8T8efGBbWobaoqwK9VOcJKHoT6kQ8XuCeJP31VDT91gGThLL6NdhSPXsXmkAZl8CF39cws+sruexRsB/GdMUEw+BDTNnFN6qJ2QGRffCEme+D4HEGdxHPKCcGp7dtWDaNWBvKJPdIngvhTXk5R9NwcdvdaCdycCtM5AOsD/5U3IOrABMclAIxxFRSFlPm9QuUEVYXo75bdEnegyGxAxt/AFQYPBvo0kIWlNIeYcJqjJivbzWC6ptUaPyuYoinTJ8DbhYuKc47tcLEJwNJeadL9XeNHu46HkPnXztaFn+BPTHiogiDmnjRL8le+PLVck/OHXEJleOXEEWXafgo+bUhmNE9CpXYNqVff3sponaHwQ9896q7c2TgarGx7XzrnoWXUoXYHTqC1qt/+GyC3NiCjyflwxdJAVcr1rsuLy0iNhiDPISV3Y6GA3tqQuxPPgot2L21CakVnl5e4xoSbHv1hsij/O5hX1LMHBw9N6TJFmzzssct3jARM1FcuKKnDRrGI+ZiZlBNSfGABN+HXobG026DnTeQ+Ao3VLmjFpka7kL40ZIAw3fG946NNp3tj9EM/0dZ6CFVoqvkWpRAgEabaotl+yYUmPaGygR12snqk4InB8EhDBmOKPqcTT7CfLvaRuGqKnbgDw7whGdvYn+cZtlQ6Y1BPQ== x-forefront-antispam-report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:DM6PR12MB3340.namprd12.prod.outlook.com;PTR:;CAT:NONE;SFS:(4636009)(136003)(39860400002)(346002)(366004)(396003)(376002)(5660300002)(9686003)(8936002)(7696005)(186003)(33656002)(54906003)(53546011)(122000001)(4326008)(83380400001)(86362001)(26005)(38100700002)(52536014)(316002)(55016002)(76116006)(71200400001)(66556008)(66476007)(66946007)(19627405001)(64756008)(66446008)(19627235002)(110136005)(6506007)(478600001)(8676002)(2906002)(38070700004);DIR:OUT;SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?Windows-1252?Q?/oDKBAz/YboHpdzGiNfSe1oUM9LWLiqb81OjB07GNLzDLGw4DCsgNLxh?= =?Windows-1252?Q?THanthr9v0ZTn5JGbR4PU+CLJPTUfXcd/qwWISYugN8EModNF3pC/cUb?= =?Windows-1252?Q?dbABy529bIoRunASlYBzi56bHcL7rx5A8e1KT8yEqzjhEgoEhEIbC4DX?= =?Windows-1252?Q?wMyNTNJSk7MGVw116K60yZn8yq36mtqRIqMw7BrViiPj6gfmya9qqOkP?= =?Windows-1252?Q?4nuaPkpGMvzLzhMXlVkK+PPsFI3YyV/y/dz2+qhUsp686y7LKcEGT9+N?= =?Windows-1252?Q?zqX3vPZStA/K+5o23jReKsmmeZN84SR9JAhG1rqCZ9WbZY5O7EF1xfrg?= =?Windows-1252?Q?C3XMisYDRQ/VHoAKPN01l7bdmfsN+FLybuQ7LpEK4y4p+jpz/YrQV2oK?= =?Windows-1252?Q?hgwVteWvMAZsA4Wr4EkZOej3pGB9zbd20q/wJtlYss9nz5ak2IyzTaMC?= =?Windows-1252?Q?yJThcBaqx8KoBKCZjh2Zn2wVzvRydqFN1k/9IdU9iE1lU64FCSqItf00?= =?Windows-1252?Q?3S3rtG9Xmr6uAJO8Z6SSv+zXGI4qqL+PHVmGEmgxZ3b7wRhDZnykZIaP?= =?Windows-1252?Q?qaFOPUwKoLj12FzJ1hUII1e001sCLaelFsesJNi1WFAQIjf0bdSnE4pB?= =?Windows-1252?Q?5fTSd87KvhgrALkFSKNjbB1S/qcPjTVL6HHYAPczZGTpq//9OXXIvXNp?= =?Windows-1252?Q?fgI3d8uBk292myoiBX89Jjc/+CQGtrgitwX4ujhfXtJhp/earLoGVs0t?= =?Windows-1252?Q?DAAg63WtcrbSDXJWoiU65DVHIiFofWmm65T36zr6o8vkHoV9g7xxBAJp?= =?Windows-1252?Q?QcT5jI0Of05PaTzLkBnXV/qROWlGlETKsHn7sl9g8y8h+k/fFyeguQ5Z?= =?Windows-1252?Q?TDh3lB+uF5uY5wJtX0jyJbYPwkgKBhvaWO1JhTrIy6YjexbYWrwapo3Z?= =?Windows-1252?Q?5uU9AwjMJN8CY47SNfYYdRve9ent8TjuEtyLqcViyBmgjw5IcO30v2WR?= =?Windows-1252?Q?INOTnyekokKZUXBOC4yxs2kiqIdwpLOAaDbn0hzRysUC0Iqknh3QVeQx?= =?Windows-1252?Q?fC75QRTddfMdKm/tBLvDkuRnyNeym0DMiIZrUkvxeCxIAQuXTKHebd0F?= =?Windows-1252?Q?iUy6hJDw8A/bnRulFhp+giVFXMlkpCKmIX53sziAzGg+7htGgo1uaCx7?= =?Windows-1252?Q?qVplsuwafIBL7Mqt8Bqp5T0IZ2DLTyOKAUBI8qGDzZnfRCDuhn1oi3z5?= =?Windows-1252?Q?4syNdVjEBPuxjmq0Zha8mlT3RaUoOBUxyGK9PE1kqbnEDXtkXcLDIOGw?= =?Windows-1252?Q?flWnHDarkZe1sYs6wvcg4ASGazDErlgNcveyUn1n+dOoD2/91uzaG6tC?= =?Windows-1252?Q?69p9kJFf2/MFHtb31DNMW4P2RoQxUjkLftX1MpqJpp4k1m16MU57amgA?= MIME-Version: 1.0 X-OriginatorOrg: Nvidia.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: DM6PR12MB3340.namprd12.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 70d1cdb3-4c72-4afe-ba57-08d94c6ca4ba X-MS-Exchange-CrossTenant-originalarrivaltime: 21 Jul 2021 17:26:15.2036 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 43083d15-7273-40c1-b7db-39efd9ccc17a X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: WbHYWuPoOMkQLYhU+tNDE96SuwsdwfWYP26yAb4ldt5j3qvGTFs1dpTO0SLdeuHK8AI7GOvPb5MeyInt6Vvl4g== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR12MB4059 Content-Language: en-US Content-Type: multipart/alternative; boundary="_000_DM6PR12MB3340793591631F7BD79E120ECBE39DM6PR12MB3340namp_" --_000_DM6PR12MB3340793591631F7BD79E120ECBE39DM6PR12MB3340namp_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Does this look good for text to add "Linux distro boot generally relies on an initial ramdisk (initrd) which is provided by the loader, and which contains additional kernel modules (for storage and network, for instance), and the initial user space startup code, i.e., the code which brings up the user space side of the entire OS. In order to provide a standard method to locate this file, the GUID defined in this file is used to describe the device path for a LoadFile2 Protocol instance that is responsible for loading the initr= d file" Also, the patch does have {OvmfPkg =3D> MdePkg}/Include/Guid/LinuxEfiInitrdMedia.h | 0 3 files changed, 5 insertions(+), 1 deletion(-) rename {OvmfPkg =3D> MdePkg}/Include/Guid/LinuxEfiInitrdMedia.h (100%) [snip] diff --git a/OvmfPkg/Include/Guid/LinuxEfiInitrdMedia.h b/MdePkg/Include/Gu= id/LinuxEfiInitrdMedia.h similarity index 100% rename from OvmfPkg/Include/Guid/LinuxEfiInitrdMedia.h rename to MdePkg/Include/Guid/LinuxEfiInitrdMedia.h Thanks, Jeff ________________________________ From: Kinney, Michael D Sent: Wednesday, July 21, 2021 9:38 AM To: Jeff Brasen ; Ard Biesheuvel ; Kin= ney, Michael D Cc: devel@edk2.groups.io ; ardb+tianocore@kernel.org = ; Justen, Jordan L ; = gaoliming@byosoft.com.cn ; Liu, Zhiguang ; Samer El-Haj-Mahmoud Subject: RE: [edk2-devel] [PATCH 1/1] MdePkg: add definition of LINUX_EFI_I= NITRD_MEDIA_GUID External email: Use caution opening links or attachments Hi Ard, If this device path node is considered as part of the standard interface be= tween the Linux kernel and firmware, then it does make sense for it to be in the MdePkg. We usually t= ry to reference a public specification in the include file that defines the interface. In this case, since there is no public document, but it is part of the Linu= x kernel assumptions, can the include file for the GUID provide pointers to the Linux kernel that= uses the GUID and describe how the GUID is produced by the FW and consumed by the Linux kerne= l? I also see that this patch appears to be incomplete. There is an OvmfPkg/I= nclude/Guid/LinuxEfiInitrdMedia.h file in the OvmfPkg. Shouldn=92t that file also be moved to the MdePkg as = part of this patch? Thanks, Mike From: Jeff Brasen Sent: Tuesday, July 20, 2021 9:59 AM To: Ard Biesheuvel ; Kinney, Michael D Cc: devel@edk2.groups.io; ardb+tianocore@kernel.org; Justen, Jordan L ; gaoliming@byosoft.com.cn; Liu, Zhiguang ; Samer El-Haj-Mahmoud Subject: Re: [edk2-devel] [PATCH 1/1] MdePkg: add definition of LINUX_EFI_I= NITRD_MEDIA_GUID In my opinion MdePkg is where this should be as it is meant to be used by m= ultiple software entities (linux kernel, grub, edk2, coreboot w/ uefi bindi= ng) and probably should be documented in some spec (Although, I am not sure= which one would make sense) I am fine with MdeModulePkg as well though. Thanks, Jeff ________________________________ From: Ard Biesheuvel > Sent: Friday, July 16, 2021 9:56 AM To: Kinney, Michael D > Cc: Jeff Brasen >; devel@edk2= .groups.io >; ardb+tianocore@kernel.org >; Justen, J= ordan L >; gaol= iming@byosoft.com.cn >; Liu, Zhiguang >; Samer El-Haj-Mahmoud > Subject: Re: [edk2-devel] [PATCH 1/1] MdePkg: add definition of LINUX_EFI_I= NITRD_MEDIA_GUID External email: Use caution opening links or attachments On Fri, 16 Jul 2021 at 17:00, Kinney, Michael D > wrote: > > Hi Ard, > > I see you were involved in the OS side changes. > > Can you explain what is required for the FW <-> OS interface with respect= to Load File Protocol and this media device path node. > > What happens if this media device path node is not present? What breaks? > > Trying to figure out if this is a required interop feature (MdePkg candid= ate) or an EDK II specific extension (MdeModulePkg candidate). > Let me give some context first: Linux distro boot generally relies on an initial ramdisk (initrd) which is provided by the loader, and which contains additional kernel modules (for storage and netwerk, for instance), and the initial user space startup code, ie., the code which brings up the user space side of the entire OS. Before we introduced this media path, the only way for a EFI pre-OS loader (such as GRUB) to provide this initrd was to copy it into DRAM somewhere, and use a arch-specific method of passing the DRAM address and size to the OS (x86 uses struct bootparam, whereas ARM uses device tree). It also requires knowledge on the part of GRUB regarding which parts of DRAM are suitable for holding an initrd image. For measured boot scenarios, it may be an advantage not to have the initrd linger in DRAM for longer that necessary, and we actually intend to measure the initrd loaded via the new method right after it has been loaded this way. To avoid extending this to other architectures such as RISC-V, I decided to introduce a special vendor media path for Linux initrd images, which GRUB et al can implement, which provides the initrd image when the OS loader that consumes it asks for it. So for Linux on x86 or ARM, this is optional, given that support for the old method is not going away any time soon. For RISC-V, I suggested that only the new method be implemented, but I am not sure what the status is there. Note that many embedded style systems don't use GRUB, and may not use initrds to begin with. OTOH, U-Boot also implements support for the Linux initrd vendor media path, and work is ongoing to add measured boot support as well. In any case, I don't have a strong preference where this should live, as long as it is in a generic place where all architectures can use it. -- Ard. --_000_DM6PR12MB3340793591631F7BD79E120ECBE39DM6PR12MB3340namp_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
Does this look good for text to add

"Linux distro b= oot generally relies on an initial ramdisk (initrd)
which is provided by= the loader, and which contains additional kernel
modules (for storage= and network, for instance), and the initial user
space startup code, = i.e., the code which brings up the user space side
of the entire OS.
In order to provide a standard method to locate this file,
the GUID defined in this file is used to describe the device path
for a LoadFile2 Protocol instance that is responsible for loading the initr= d file"


Also, the patch does have
=  {OvmfPkg =3D> MdePkg}/Include/Guid/LinuxEfiInitrdMedia.h | 0
=  3 files changed, 5 insertions(+), 1 deletion(-)
=  rename {OvmfPkg =3D> MdePkg}/Include/Guid/LinuxEfiInitrdMedia.h (100%)<= br style=3D"color:rgb(32, 31, 30);font-family:"Segoe UI", "S= egoe UI Web (West European)", "Segoe UI", -apple-system, Bli= nkMacSystemFont, Roboto, "Helvetica Neue", sans-serif;font-size:1= 4.6667px;background-color:rgb(255, 255, 255)"> [snip]
= diff --git a/OvmfPkg/Include/Guid/LinuxEfiInitrdMedia.h b/MdePkg/Include/Guid/L= inuxEfiInitrdMedia.h
= similarity index 100%
= rename from OvmfPkg/Include/Guid/LinuxEfiInitrdMedia.h
= rename to MdePkg/Include/Guid/LinuxEfiInitrdMedia.h
=
=

Thanks,

Jeff

From: Kinney, Michael D <= ;michael.d.kinney@intel.com>
Sent: Wednesday, July 21, 2021 9:38 AM
To: Jeff Brasen <jbrasen@nvidia.com>; Ard Biesheuvel <ardb@= kernel.org>; Kinney, Michael D <michael.d.kinney@intel.com>
Cc: devel@edk2.groups.io <devel@edk2.groups.io>; ardb+tianocor= e@kernel.org <ardb+tianocore@kernel.org>; Justen, Jordan L <jordan= .l.justen@intel.com>; gaoliming@byosoft.com.cn <gaoliming@byosoft.com= .cn>; Liu, Zhiguang <zhiguang.liu@intel.com>; Samer El-Haj-Mahmoud <Samer.El-Haj-Mahmoud@arm.com>
Subject: RE: [edk2-devel] [PATCH 1/1] MdePkg: add definition of LINU= X_EFI_INITRD_MEDIA_GUID
 
External email: Us= e caution opening links or attachments

Hi Ard,

 

If this device path node is consi= dered as part of the standard interface between the Linux kernel and

firmware, then it does make sense= for it to be in the MdePkg.  We us= ually try to reference a public

specification in the include file= that defines the interface.

 

In this case, since there is no p= ublic document, but it is part of the Linux kernel assumptions,

can the include file for the GUID= provide pointers to the Linux kernel that uses the GUID and

describe how the GUID is produced= by the FW and consumed by the Linux kernel?

 

I also see that this patch appear= s to be incomplete.  There is an OvmfPkg/Include/Guid/LinuxEfiInitrdMedia.h=

file in the OvmfPkg.  Shouldn=92t that file also be moved to the = MdePkg as part of this patch?

 

Thanks,

 

Mike

 

From: Jeff Brasen <jbrasen@nvidia.com>
Sent: Tuesday, July 20, 2021 9:59 AM
To: Ard Biesheuvel <ardb@kernel.org>; Kinney, Michael D <mi= chael.d.kinney@intel.com>
Cc: devel@edk2.groups.io; ardb+tianocore@kernel.org; Justen, Jordan = L <jordan.l.justen@intel.com>; gaoliming@byosoft.com.cn; Liu, Zhiguan= g <zhiguang.liu@intel.com>; Samer El-Haj-Mahmoud <Samer.El-Haj-Mah= moud@arm.com>
Subject: Re: [edk2-devel] [PATCH 1/1] MdePkg: add definition of LINU= X_EFI_INITRD_MEDIA_GUID

 

In m= y opinion MdePkg is where this should be as it is meant to be used by multi= ple software entities (linux kernel, grub, edk2, coreboot w/ uefi binding) = and probably should be documented in some spec (Although, I am not sure which one would make sense)

&nbs= p;

I am= fine with MdeModulePkg as well though.

&nbs= p;

Thanks,

Jeff

From: Ard Biesheuvel <ardb@kernel.org>
Sent: Friday, July 16, 2021 9:56 AM
To: Kinney, Michael D <michael.d.kinney@intel.com>
Cc: Jeff Brasen <jbrasen@nv= idia.com>; devel@edk2.groups.io <devel@edk2.groups.io>; ardb+tianocore@kernel.org = <ardb+tianocore@kernel.org<= /a>>; Justen, Jordan L <= jordan.l.justen@intel.com>; gaoliming@byosoft.com.cn &l= t;gaoliming@byosoft.com.cn&= gt;; Liu, Zhiguang <zhiguang.l= iu@intel.com>; Samer El-Haj-Mahmoud <Samer.El-Haj-Mahmoud@arm.com>
Subject: Re: [edk2-devel] [PATCH 1/1] MdePkg: add definition of LINU= X_EFI_INITRD_MEDIA_GUID

 

External email: Use caution openi= ng links or attachments


On Fri, 16 Jul 2021 at 17:00, Kinney, Michael D
<michael.d.kinney@intel.co= m> wrote:
>
> Hi Ard,
>
> I see you were involved in the OS side changes.
>
> Can you explain what is required for the FW <-> OS interface wit= h respect to Load File Protocol and this media device path node.
>
> What happens if this media device path node is not present?  What= breaks?
>
> Trying to figure out if this is a required interop feature (MdePkg can= didate) or an EDK II specific extension (MdeModulePkg candidate).
>

Let me give some context first:

Linux distro boot generally relies on an initial ramdisk (initrd)
which is provided by the loader, and which contains additional kernel
modules (for storage and netwerk, for instance), and the initial user
space startup code, ie., the code which brings up the user space side
of the entire OS.

Before we introduced this media path, the only way for a EFI pre-OS
loader (such as GRUB) to provide this initrd was to copy it into DRAM
somewhere, and use a arch-specific method of passing the DRAM address
and size to the OS (x86 uses struct bootparam, whereas ARM uses device
tree). It also requires knowledge on the part of GRUB regarding which
parts of DRAM are suitable for holding an initrd image. For measured
boot scenarios, it may be an advantage not to have the initrd linger
in DRAM for longer that necessary, and we actually intend to measure
the initrd loaded via the new method right after it has been loaded
this way.

To avoid extending this to other architectures such as RISC-V, I
decided to introduce a special vendor media path for Linux initrd
images, which GRUB et al can implement, which provides the initrd
image when the OS loader that consumes it asks for it.

So for Linux on x86 or ARM, this is optional, given that support for
the old method is not going away any time soon. For RISC-V, I
suggested that only the new method be implemented, but I am not sure
what the status is there. Note that many embedded style systems don't
use GRUB, and may not use initrds to begin with. OTOH, U-Boot also
implements support for the Linux initrd vendor media path, and work is
ongoing to add measured boot support as well.

In any case, I don't have a strong preference where this should live,
as long as it is in a generic place where all architectures can use
it.

--
Ard.

--_000_DM6PR12MB3340793591631F7BD79E120ECBE39DM6PR12MB3340namp_--