* [PATCH 1/1] MdePkg: add definition of LINUX_EFI_INITRD_MEDIA_GUID
@ 2021-07-15 18:07 Jeff Brasen
2021-07-15 22:56 ` [edk2-devel] " Michael D Kinney
0 siblings, 1 reply; 12+ messages in thread
From: Jeff Brasen @ 2021-07-15 18:07 UTC (permalink / raw)
To: devel
Cc: ardb+tianocore, michael.d.kinney, jordan.l.justen, gaoliming,
zhiguang.liu, Jeff Brasen
Add LINUX_EFI_INITRD_MEDIA_GUID to our collection of GUID definitions,
it can be used in a media device path to specify a Linux style initrd
that can be loaded by the OS using the LoadFile2 protocol.
Move these defines to MdePkg from OvmfPkg as these are relevant to
non-OVMF targets as well.
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2564
Signed-off-by: Jeff Brasen <jbrasen@nvidia.com>
---
MdePkg/MdePkg.dec | 5 +++++
OvmfPkg/OvmfPkg.dec | 1 -
{OvmfPkg => MdePkg}/Include/Guid/LinuxEfiInitrdMedia.h | 0
3 files changed, 5 insertions(+), 1 deletion(-)
rename {OvmfPkg => MdePkg}/Include/Guid/LinuxEfiInitrdMedia.h (100%)
diff --git a/MdePkg/MdePkg.dec b/MdePkg/MdePkg.dec
index c5319fdd71ca..a28a2daaffa8 100644
--- a/MdePkg/MdePkg.dec
+++ b/MdePkg/MdePkg.dec
@@ -818,6 +818,11 @@ [Guids]
#
gTianoCustomDecompressGuid = { 0xA31280AD, 0x481E, 0x41B6, { 0x95, 0xE8, 0x12, 0x7F, 0x4C, 0x98, 0x47, 0x79 }}
+ #
+ # GUID used to provide initrd to linux via LoadFile2 protocol
+ #
+ gLinuxEfiInitrdMediaGuid = {0x5568e427, 0x68fc, 0x4f3d, {0xac, 0x74, 0xca, 0x55, 0x52, 0x31, 0xcc, 0x68}}
+
[Guids.IA32, Guids.X64]
## Include/Guid/Cper.h
gEfiIa32X64ErrorTypeCacheCheckGuid = { 0xA55701F5, 0xE3EF, 0x43de, { 0xAC, 0x72, 0x24, 0x9B, 0x57, 0x3F, 0xAD, 0x2C }}
diff --git a/OvmfPkg/OvmfPkg.dec b/OvmfPkg/OvmfPkg.dec
index 6ae733f6e39f..3153f5ae4540 100644
--- a/OvmfPkg/OvmfPkg.dec
+++ b/OvmfPkg/OvmfPkg.dec
@@ -118,7 +118,6 @@ [Guids]
gMicrosoftVendorGuid = {0x77fa9abd, 0x0359, 0x4d32, {0xbd, 0x60, 0x28, 0xf4, 0xe7, 0x8f, 0x78, 0x4b}}
gEfiLegacyBiosGuid = {0x2E3044AC, 0x879F, 0x490F, {0x97, 0x60, 0xBB, 0xDF, 0xAF, 0x69, 0x5F, 0x50}}
gEfiLegacyDevOrderVariableGuid = {0xa56074db, 0x65fe, 0x45f7, {0xbd, 0x21, 0x2d, 0x2b, 0xdd, 0x8e, 0x96, 0x52}}
- gLinuxEfiInitrdMediaGuid = {0x5568e427, 0x68fc, 0x4f3d, {0xac, 0x74, 0xca, 0x55, 0x52, 0x31, 0xcc, 0x68}}
gQemuKernelLoaderFsMediaGuid = {0x1428f772, 0xb64a, 0x441e, {0xb8, 0xc3, 0x9e, 0xbd, 0xd7, 0xf8, 0x93, 0xc7}}
gGrubFileGuid = {0xb5ae312c, 0xbc8a, 0x43b1, {0x9c, 0x62, 0xeb, 0xb8, 0x26, 0xdd, 0x5d, 0x07}}
gConfidentialComputingSecretGuid = {0xadf956ad, 0xe98c, 0x484c, {0xae, 0x11, 0xb5, 0x1c, 0x7d, 0x33, 0x64, 0x47}}
diff --git a/OvmfPkg/Include/Guid/LinuxEfiInitrdMedia.h b/MdePkg/Include/Guid/LinuxEfiInitrdMedia.h
similarity index 100%
rename from OvmfPkg/Include/Guid/LinuxEfiInitrdMedia.h
rename to MdePkg/Include/Guid/LinuxEfiInitrdMedia.h
--
2.25.1
^ permalink raw reply related [flat|nested] 12+ messages in thread
* Re: [edk2-devel] [PATCH 1/1] MdePkg: add definition of LINUX_EFI_INITRD_MEDIA_GUID
2021-07-15 18:07 [PATCH 1/1] MdePkg: add definition of LINUX_EFI_INITRD_MEDIA_GUID Jeff Brasen
@ 2021-07-15 22:56 ` Michael D Kinney
2021-07-15 23:20 ` Jeff Brasen
0 siblings, 1 reply; 12+ messages in thread
From: Michael D Kinney @ 2021-07-15 22:56 UTC (permalink / raw)
To: devel@edk2.groups.io, jbrasen@nvidia.com, Kinney, Michael D
Cc: ardb+tianocore@kernel.org, Justen, Jordan L,
gaoliming@byosoft.com.cn, Liu, Zhiguang
Is this GUID defined in an industry standard or public spec?
If not, then MdeModulePkg may be a better choice if this is a GUID defines for EDK II extensions.
Mike
> -----Original Message-----
> From: devel@edk2.groups.io <devel@edk2.groups.io> On Behalf Of Jeff Brasen via groups.io
> Sent: Thursday, July 15, 2021 11:08 AM
> To: devel@edk2.groups.io
> Cc: ardb+tianocore@kernel.org; Kinney, Michael D <michael.d.kinney@intel.com>; Justen, Jordan L
> <jordan.l.justen@intel.com>; gaoliming@byosoft.com.cn; Liu, Zhiguang <zhiguang.liu@intel.com>; Jeff Brasen
> <jbrasen@nvidia.com>
> Subject: [edk2-devel] [PATCH 1/1] MdePkg: add definition of LINUX_EFI_INITRD_MEDIA_GUID
>
> Add LINUX_EFI_INITRD_MEDIA_GUID to our collection of GUID definitions,
> it can be used in a media device path to specify a Linux style initrd
> that can be loaded by the OS using the LoadFile2 protocol.
>
> Move these defines to MdePkg from OvmfPkg as these are relevant to
> non-OVMF targets as well.
>
> Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2564
> Signed-off-by: Jeff Brasen <jbrasen@nvidia.com>
> ---
> MdePkg/MdePkg.dec | 5 +++++
> OvmfPkg/OvmfPkg.dec | 1 -
> {OvmfPkg => MdePkg}/Include/Guid/LinuxEfiInitrdMedia.h | 0
> 3 files changed, 5 insertions(+), 1 deletion(-)
> rename {OvmfPkg => MdePkg}/Include/Guid/LinuxEfiInitrdMedia.h (100%)
>
> diff --git a/MdePkg/MdePkg.dec b/MdePkg/MdePkg.dec
> index c5319fdd71ca..a28a2daaffa8 100644
> --- a/MdePkg/MdePkg.dec
> +++ b/MdePkg/MdePkg.dec
> @@ -818,6 +818,11 @@ [Guids]
> #
> gTianoCustomDecompressGuid = { 0xA31280AD, 0x481E, 0x41B6, { 0x95, 0xE8, 0x12, 0x7F, 0x4C, 0x98, 0x47, 0x79 }}
>
> + #
> + # GUID used to provide initrd to linux via LoadFile2 protocol
> + #
> + gLinuxEfiInitrdMediaGuid = {0x5568e427, 0x68fc, 0x4f3d, {0xac, 0x74, 0xca, 0x55, 0x52, 0x31, 0xcc, 0x68}}
> +
> [Guids.IA32, Guids.X64]
> ## Include/Guid/Cper.h
> gEfiIa32X64ErrorTypeCacheCheckGuid = { 0xA55701F5, 0xE3EF, 0x43de, { 0xAC, 0x72, 0x24, 0x9B, 0x57, 0x3F, 0xAD, 0x2C }}
> diff --git a/OvmfPkg/OvmfPkg.dec b/OvmfPkg/OvmfPkg.dec
> index 6ae733f6e39f..3153f5ae4540 100644
> --- a/OvmfPkg/OvmfPkg.dec
> +++ b/OvmfPkg/OvmfPkg.dec
> @@ -118,7 +118,6 @@ [Guids]
> gMicrosoftVendorGuid = {0x77fa9abd, 0x0359, 0x4d32, {0xbd, 0x60, 0x28, 0xf4, 0xe7, 0x8f, 0x78, 0x4b}}
> gEfiLegacyBiosGuid = {0x2E3044AC, 0x879F, 0x490F, {0x97, 0x60, 0xBB, 0xDF, 0xAF, 0x69, 0x5F, 0x50}}
> gEfiLegacyDevOrderVariableGuid = {0xa56074db, 0x65fe, 0x45f7, {0xbd, 0x21, 0x2d, 0x2b, 0xdd, 0x8e, 0x96, 0x52}}
> - gLinuxEfiInitrdMediaGuid = {0x5568e427, 0x68fc, 0x4f3d, {0xac, 0x74, 0xca, 0x55, 0x52, 0x31, 0xcc, 0x68}}
> gQemuKernelLoaderFsMediaGuid = {0x1428f772, 0xb64a, 0x441e, {0xb8, 0xc3, 0x9e, 0xbd, 0xd7, 0xf8, 0x93, 0xc7}}
> gGrubFileGuid = {0xb5ae312c, 0xbc8a, 0x43b1, {0x9c, 0x62, 0xeb, 0xb8, 0x26, 0xdd, 0x5d, 0x07}}
> gConfidentialComputingSecretGuid = {0xadf956ad, 0xe98c, 0x484c, {0xae, 0x11, 0xb5, 0x1c, 0x7d, 0x33, 0x64, 0x47}}
> diff --git a/OvmfPkg/Include/Guid/LinuxEfiInitrdMedia.h b/MdePkg/Include/Guid/LinuxEfiInitrdMedia.h
> similarity index 100%
> rename from OvmfPkg/Include/Guid/LinuxEfiInitrdMedia.h
> rename to MdePkg/Include/Guid/LinuxEfiInitrdMedia.h
> --
> 2.25.1
>
>
>
>
>
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [edk2-devel] [PATCH 1/1] MdePkg: add definition of LINUX_EFI_INITRD_MEDIA_GUID
2021-07-15 22:56 ` [edk2-devel] " Michael D Kinney
@ 2021-07-15 23:20 ` Jeff Brasen
2021-07-16 12:09 ` Ard Biesheuvel
0 siblings, 1 reply; 12+ messages in thread
From: Jeff Brasen @ 2021-07-15 23:20 UTC (permalink / raw)
To: Kinney, Michael D, devel@edk2.groups.io
Cc: ardb+tianocore@kernel.org, Justen, Jordan L,
gaoliming@byosoft.com.cn, Liu, Zhiguang, Samer El-Haj-Mahmoud
[-- Attachment #1: Type: text/plain, Size: 4463 bytes --]
The GUID is used by the linux kernel but not sure if part of any formal spec
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/include/linux/efi.h?h=v5.14-rc1&id=ec93fc371f014a6fb483e3556061ecad4b40735c
If we feel MdeModulePkg is a better place I am fine with that as well and can release a v2 version.
Thanks,
Jeff
________________________________
From: Kinney, Michael D <michael.d.kinney@intel.com>
Sent: Thursday, July 15, 2021 4:56 PM
To: devel@edk2.groups.io <devel@edk2.groups.io>; Jeff Brasen <jbrasen@nvidia.com>; Kinney, Michael D <michael.d.kinney@intel.com>
Cc: ardb+tianocore@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>
Subject: RE: [edk2-devel] [PATCH 1/1] MdePkg: add definition of LINUX_EFI_INITRD_MEDIA_GUID
External email: Use caution opening links or attachments
Is this GUID defined in an industry standard or public spec?
If not, then MdeModulePkg may be a better choice if this is a GUID defines for EDK II extensions.
Mike
> -----Original Message-----
> From: devel@edk2.groups.io <devel@edk2.groups.io> On Behalf Of Jeff Brasen via groups.io
> Sent: Thursday, July 15, 2021 11:08 AM
> To: devel@edk2.groups.io
> Cc: ardb+tianocore@kernel.org; Kinney, Michael D <michael.d.kinney@intel.com>; Justen, Jordan L
> <jordan.l.justen@intel.com>; gaoliming@byosoft.com.cn; Liu, Zhiguang <zhiguang.liu@intel.com>; Jeff Brasen
> <jbrasen@nvidia.com>
> Subject: [edk2-devel] [PATCH 1/1] MdePkg: add definition of LINUX_EFI_INITRD_MEDIA_GUID
>
> Add LINUX_EFI_INITRD_MEDIA_GUID to our collection of GUID definitions,
> it can be used in a media device path to specify a Linux style initrd
> that can be loaded by the OS using the LoadFile2 protocol.
>
> Move these defines to MdePkg from OvmfPkg as these are relevant to
> non-OVMF targets as well.
>
> Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2564
> Signed-off-by: Jeff Brasen <jbrasen@nvidia.com>
> ---
> MdePkg/MdePkg.dec | 5 +++++
> OvmfPkg/OvmfPkg.dec | 1 -
> {OvmfPkg => MdePkg}/Include/Guid/LinuxEfiInitrdMedia.h | 0
> 3 files changed, 5 insertions(+), 1 deletion(-)
> rename {OvmfPkg => MdePkg}/Include/Guid/LinuxEfiInitrdMedia.h (100%)
>
> diff --git a/MdePkg/MdePkg.dec b/MdePkg/MdePkg.dec
> index c5319fdd71ca..a28a2daaffa8 100644
> --- a/MdePkg/MdePkg.dec
> +++ b/MdePkg/MdePkg.dec
> @@ -818,6 +818,11 @@ [Guids]
> #
> gTianoCustomDecompressGuid = { 0xA31280AD, 0x481E, 0x41B6, { 0x95, 0xE8, 0x12, 0x7F, 0x4C, 0x98, 0x47, 0x79 }}
>
> + #
> + # GUID used to provide initrd to linux via LoadFile2 protocol
> + #
> + gLinuxEfiInitrdMediaGuid = {0x5568e427, 0x68fc, 0x4f3d, {0xac, 0x74, 0xca, 0x55, 0x52, 0x31, 0xcc, 0x68}}
> +
> [Guids.IA32, Guids.X64]
> ## Include/Guid/Cper.h
> gEfiIa32X64ErrorTypeCacheCheckGuid = { 0xA55701F5, 0xE3EF, 0x43de, { 0xAC, 0x72, 0x24, 0x9B, 0x57, 0x3F, 0xAD, 0x2C }}
> diff --git a/OvmfPkg/OvmfPkg.dec b/OvmfPkg/OvmfPkg.dec
> index 6ae733f6e39f..3153f5ae4540 100644
> --- a/OvmfPkg/OvmfPkg.dec
> +++ b/OvmfPkg/OvmfPkg.dec
> @@ -118,7 +118,6 @@ [Guids]
> gMicrosoftVendorGuid = {0x77fa9abd, 0x0359, 0x4d32, {0xbd, 0x60, 0x28, 0xf4, 0xe7, 0x8f, 0x78, 0x4b}}
> gEfiLegacyBiosGuid = {0x2E3044AC, 0x879F, 0x490F, {0x97, 0x60, 0xBB, 0xDF, 0xAF, 0x69, 0x5F, 0x50}}
> gEfiLegacyDevOrderVariableGuid = {0xa56074db, 0x65fe, 0x45f7, {0xbd, 0x21, 0x2d, 0x2b, 0xdd, 0x8e, 0x96, 0x52}}
> - gLinuxEfiInitrdMediaGuid = {0x5568e427, 0x68fc, 0x4f3d, {0xac, 0x74, 0xca, 0x55, 0x52, 0x31, 0xcc, 0x68}}
> gQemuKernelLoaderFsMediaGuid = {0x1428f772, 0xb64a, 0x441e, {0xb8, 0xc3, 0x9e, 0xbd, 0xd7, 0xf8, 0x93, 0xc7}}
> gGrubFileGuid = {0xb5ae312c, 0xbc8a, 0x43b1, {0x9c, 0x62, 0xeb, 0xb8, 0x26, 0xdd, 0x5d, 0x07}}
> gConfidentialComputingSecretGuid = {0xadf956ad, 0xe98c, 0x484c, {0xae, 0x11, 0xb5, 0x1c, 0x7d, 0x33, 0x64, 0x47}}
> diff --git a/OvmfPkg/Include/Guid/LinuxEfiInitrdMedia.h b/MdePkg/Include/Guid/LinuxEfiInitrdMedia.h
> similarity index 100%
> rename from OvmfPkg/Include/Guid/LinuxEfiInitrdMedia.h
> rename to MdePkg/Include/Guid/LinuxEfiInitrdMedia.h
> --
> 2.25.1
>
>
>
>
>
[-- Attachment #2: Type: text/html, Size: 7733 bytes --]
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [edk2-devel] [PATCH 1/1] MdePkg: add definition of LINUX_EFI_INITRD_MEDIA_GUID
2021-07-15 23:20 ` Jeff Brasen
@ 2021-07-16 12:09 ` Ard Biesheuvel
2021-07-16 15:00 ` Michael D Kinney
0 siblings, 1 reply; 12+ messages in thread
From: Ard Biesheuvel @ 2021-07-16 12:09 UTC (permalink / raw)
To: Jeff Brasen
Cc: Kinney, Michael D, devel@edk2.groups.io,
ardb+tianocore@kernel.org, Justen, Jordan L,
gaoliming@byosoft.com.cn, Liu, Zhiguang, Samer El-Haj-Mahmoud
On Fri, 16 Jul 2021 at 01:20, Jeff Brasen <jbrasen@nvidia.com> wrote:
>
> The GUID is used by the linux kernel but not sure if part of any formal spec
>
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/include/linux/efi.h?h=v5.14-rc1&id=ec93fc371f014a6fb483e3556061ecad4b40735c
>
> If we feel MdeModulePkg is a better place I am fine with that as well and can release a v2 version.
>
For this patch, whichever package it lands in:
Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
>
> ________________________________
> From: Kinney, Michael D <michael.d.kinney@intel.com>
> Sent: Thursday, July 15, 2021 4:56 PM
> To: devel@edk2.groups.io <devel@edk2.groups.io>; Jeff Brasen <jbrasen@nvidia.com>; Kinney, Michael D <michael.d.kinney@intel.com>
> Cc: ardb+tianocore@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>
> Subject: RE: [edk2-devel] [PATCH 1/1] MdePkg: add definition of LINUX_EFI_INITRD_MEDIA_GUID
>
> External email: Use caution opening links or attachments
>
>
> Is this GUID defined in an industry standard or public spec?
>
> If not, then MdeModulePkg may be a better choice if this is a GUID defines for EDK II extensions.
>
> Mike
>
> > -----Original Message-----
> > From: devel@edk2.groups.io <devel@edk2.groups.io> On Behalf Of Jeff Brasen via groups.io
> > Sent: Thursday, July 15, 2021 11:08 AM
> > To: devel@edk2.groups.io
> > Cc: ardb+tianocore@kernel.org; Kinney, Michael D <michael.d.kinney@intel.com>; Justen, Jordan L
> > <jordan.l.justen@intel.com>; gaoliming@byosoft.com.cn; Liu, Zhiguang <zhiguang.liu@intel.com>; Jeff Brasen
> > <jbrasen@nvidia.com>
> > Subject: [edk2-devel] [PATCH 1/1] MdePkg: add definition of LINUX_EFI_INITRD_MEDIA_GUID
> >
> > Add LINUX_EFI_INITRD_MEDIA_GUID to our collection of GUID definitions,
> > it can be used in a media device path to specify a Linux style initrd
> > that can be loaded by the OS using the LoadFile2 protocol.
> >
> > Move these defines to MdePkg from OvmfPkg as these are relevant to
> > non-OVMF targets as well.
> >
> > Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2564
> > Signed-off-by: Jeff Brasen <jbrasen@nvidia.com>
> > ---
> > MdePkg/MdePkg.dec | 5 +++++
> > OvmfPkg/OvmfPkg.dec | 1 -
> > {OvmfPkg => MdePkg}/Include/Guid/LinuxEfiInitrdMedia.h | 0
> > 3 files changed, 5 insertions(+), 1 deletion(-)
> > rename {OvmfPkg => MdePkg}/Include/Guid/LinuxEfiInitrdMedia.h (100%)
> >
> > diff --git a/MdePkg/MdePkg.dec b/MdePkg/MdePkg.dec
> > index c5319fdd71ca..a28a2daaffa8 100644
> > --- a/MdePkg/MdePkg.dec
> > +++ b/MdePkg/MdePkg.dec
> > @@ -818,6 +818,11 @@ [Guids]
> > #
> > gTianoCustomDecompressGuid = { 0xA31280AD, 0x481E, 0x41B6, { 0x95, 0xE8, 0x12, 0x7F, 0x4C, 0x98, 0x47, 0x79 }}
> >
> > + #
> > + # GUID used to provide initrd to linux via LoadFile2 protocol
> > + #
> > + gLinuxEfiInitrdMediaGuid = {0x5568e427, 0x68fc, 0x4f3d, {0xac, 0x74, 0xca, 0x55, 0x52, 0x31, 0xcc, 0x68}}
> > +
> > [Guids.IA32, Guids.X64]
> > ## Include/Guid/Cper.h
> > gEfiIa32X64ErrorTypeCacheCheckGuid = { 0xA55701F5, 0xE3EF, 0x43de, { 0xAC, 0x72, 0x24, 0x9B, 0x57, 0x3F, 0xAD, 0x2C }}
> > diff --git a/OvmfPkg/OvmfPkg.dec b/OvmfPkg/OvmfPkg.dec
> > index 6ae733f6e39f..3153f5ae4540 100644
> > --- a/OvmfPkg/OvmfPkg.dec
> > +++ b/OvmfPkg/OvmfPkg.dec
> > @@ -118,7 +118,6 @@ [Guids]
> > gMicrosoftVendorGuid = {0x77fa9abd, 0x0359, 0x4d32, {0xbd, 0x60, 0x28, 0xf4, 0xe7, 0x8f, 0x78, 0x4b}}
> > gEfiLegacyBiosGuid = {0x2E3044AC, 0x879F, 0x490F, {0x97, 0x60, 0xBB, 0xDF, 0xAF, 0x69, 0x5F, 0x50}}
> > gEfiLegacyDevOrderVariableGuid = {0xa56074db, 0x65fe, 0x45f7, {0xbd, 0x21, 0x2d, 0x2b, 0xdd, 0x8e, 0x96, 0x52}}
> > - gLinuxEfiInitrdMediaGuid = {0x5568e427, 0x68fc, 0x4f3d, {0xac, 0x74, 0xca, 0x55, 0x52, 0x31, 0xcc, 0x68}}
> > gQemuKernelLoaderFsMediaGuid = {0x1428f772, 0xb64a, 0x441e, {0xb8, 0xc3, 0x9e, 0xbd, 0xd7, 0xf8, 0x93, 0xc7}}
> > gGrubFileGuid = {0xb5ae312c, 0xbc8a, 0x43b1, {0x9c, 0x62, 0xeb, 0xb8, 0x26, 0xdd, 0x5d, 0x07}}
> > gConfidentialComputingSecretGuid = {0xadf956ad, 0xe98c, 0x484c, {0xae, 0x11, 0xb5, 0x1c, 0x7d, 0x33, 0x64, 0x47}}
> > diff --git a/OvmfPkg/Include/Guid/LinuxEfiInitrdMedia.h b/MdePkg/Include/Guid/LinuxEfiInitrdMedia.h
> > similarity index 100%
> > rename from OvmfPkg/Include/Guid/LinuxEfiInitrdMedia.h
> > rename to MdePkg/Include/Guid/LinuxEfiInitrdMedia.h
> > --
> > 2.25.1
> >
> >
> >
> >
> >
>
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [edk2-devel] [PATCH 1/1] MdePkg: add definition of LINUX_EFI_INITRD_MEDIA_GUID
2021-07-16 12:09 ` Ard Biesheuvel
@ 2021-07-16 15:00 ` Michael D Kinney
2021-07-16 15:56 ` Ard Biesheuvel
0 siblings, 1 reply; 12+ messages in thread
From: Michael D Kinney @ 2021-07-16 15:00 UTC (permalink / raw)
To: Ard Biesheuvel, Jeff Brasen, 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
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 candidate) or an EDK II specific extension (MdeModulePkg candidate).
Thanks,
Mike
> -----Original Message-----
> From: Ard Biesheuvel <ardb@kernel.org>
> Sent: Friday, July 16, 2021 5:09 AM
> To: Jeff Brasen <jbrasen@nvidia.com>
> Cc: Kinney, Michael D <michael.d.kinney@intel.com>; devel@edk2.groups.io; ardb+tianocore@kernel.org; Justen, Jordan L
> <jordan.l.justen@intel.com>; 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 LINUX_EFI_INITRD_MEDIA_GUID
>
> On Fri, 16 Jul 2021 at 01:20, Jeff Brasen <jbrasen@nvidia.com> wrote:
> >
> > The GUID is used by the linux kernel but not sure if part of any formal spec
> >
> > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/include/linux/efi.h?h=v5.14-
> rc1&id=ec93fc371f014a6fb483e3556061ecad4b40735c
> >
> > If we feel MdeModulePkg is a better place I am fine with that as well and can release a v2 version.
> >
>
> For this patch, whichever package it lands in:
>
> Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
>
>
> >
> > ________________________________
> > From: Kinney, Michael D <michael.d.kinney@intel.com>
> > Sent: Thursday, July 15, 2021 4:56 PM
> > To: devel@edk2.groups.io <devel@edk2.groups.io>; Jeff Brasen <jbrasen@nvidia.com>; Kinney, Michael D
> <michael.d.kinney@intel.com>
> > Cc: ardb+tianocore@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>
> > Subject: RE: [edk2-devel] [PATCH 1/1] MdePkg: add definition of LINUX_EFI_INITRD_MEDIA_GUID
> >
> > External email: Use caution opening links or attachments
> >
> >
> > Is this GUID defined in an industry standard or public spec?
> >
> > If not, then MdeModulePkg may be a better choice if this is a GUID defines for EDK II extensions.
> >
> > Mike
> >
> > > -----Original Message-----
> > > From: devel@edk2.groups.io <devel@edk2.groups.io> On Behalf Of Jeff Brasen via groups.io
> > > Sent: Thursday, July 15, 2021 11:08 AM
> > > To: devel@edk2.groups.io
> > > Cc: ardb+tianocore@kernel.org; Kinney, Michael D <michael.d.kinney@intel.com>; Justen, Jordan L
> > > <jordan.l.justen@intel.com>; gaoliming@byosoft.com.cn; Liu, Zhiguang <zhiguang.liu@intel.com>; Jeff Brasen
> > > <jbrasen@nvidia.com>
> > > Subject: [edk2-devel] [PATCH 1/1] MdePkg: add definition of LINUX_EFI_INITRD_MEDIA_GUID
> > >
> > > Add LINUX_EFI_INITRD_MEDIA_GUID to our collection of GUID definitions,
> > > it can be used in a media device path to specify a Linux style initrd
> > > that can be loaded by the OS using the LoadFile2 protocol.
> > >
> > > Move these defines to MdePkg from OvmfPkg as these are relevant to
> > > non-OVMF targets as well.
> > >
> > > Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2564
> > > Signed-off-by: Jeff Brasen <jbrasen@nvidia.com>
> > > ---
> > > MdePkg/MdePkg.dec | 5 +++++
> > > OvmfPkg/OvmfPkg.dec | 1 -
> > > {OvmfPkg => MdePkg}/Include/Guid/LinuxEfiInitrdMedia.h | 0
> > > 3 files changed, 5 insertions(+), 1 deletion(-)
> > > rename {OvmfPkg => MdePkg}/Include/Guid/LinuxEfiInitrdMedia.h (100%)
> > >
> > > diff --git a/MdePkg/MdePkg.dec b/MdePkg/MdePkg.dec
> > > index c5319fdd71ca..a28a2daaffa8 100644
> > > --- a/MdePkg/MdePkg.dec
> > > +++ b/MdePkg/MdePkg.dec
> > > @@ -818,6 +818,11 @@ [Guids]
> > > #
> > > gTianoCustomDecompressGuid = { 0xA31280AD, 0x481E, 0x41B6, { 0x95, 0xE8, 0x12, 0x7F, 0x4C, 0x98, 0x47, 0x79 }}
> > >
> > > + #
> > > + # GUID used to provide initrd to linux via LoadFile2 protocol
> > > + #
> > > + gLinuxEfiInitrdMediaGuid = {0x5568e427, 0x68fc, 0x4f3d, {0xac, 0x74, 0xca, 0x55, 0x52, 0x31, 0xcc, 0x68}}
> > > +
> > > [Guids.IA32, Guids.X64]
> > > ## Include/Guid/Cper.h
> > > gEfiIa32X64ErrorTypeCacheCheckGuid = { 0xA55701F5, 0xE3EF, 0x43de, { 0xAC, 0x72, 0x24, 0x9B, 0x57, 0x3F, 0xAD, 0x2C
> }}
> > > diff --git a/OvmfPkg/OvmfPkg.dec b/OvmfPkg/OvmfPkg.dec
> > > index 6ae733f6e39f..3153f5ae4540 100644
> > > --- a/OvmfPkg/OvmfPkg.dec
> > > +++ b/OvmfPkg/OvmfPkg.dec
> > > @@ -118,7 +118,6 @@ [Guids]
> > > gMicrosoftVendorGuid = {0x77fa9abd, 0x0359, 0x4d32, {0xbd, 0x60, 0x28, 0xf4, 0xe7, 0x8f, 0x78,
> 0x4b}}
> > > gEfiLegacyBiosGuid = {0x2E3044AC, 0x879F, 0x490F, {0x97, 0x60, 0xBB, 0xDF, 0xAF, 0x69, 0x5F,
> 0x50}}
> > > gEfiLegacyDevOrderVariableGuid = {0xa56074db, 0x65fe, 0x45f7, {0xbd, 0x21, 0x2d, 0x2b, 0xdd, 0x8e, 0x96,
> 0x52}}
> > > - gLinuxEfiInitrdMediaGuid = {0x5568e427, 0x68fc, 0x4f3d, {0xac, 0x74, 0xca, 0x55, 0x52, 0x31, 0xcc,
> 0x68}}
> > > gQemuKernelLoaderFsMediaGuid = {0x1428f772, 0xb64a, 0x441e, {0xb8, 0xc3, 0x9e, 0xbd, 0xd7, 0xf8, 0x93,
> 0xc7}}
> > > gGrubFileGuid = {0xb5ae312c, 0xbc8a, 0x43b1, {0x9c, 0x62, 0xeb, 0xb8, 0x26, 0xdd, 0x5d,
> 0x07}}
> > > gConfidentialComputingSecretGuid = {0xadf956ad, 0xe98c, 0x484c, {0xae, 0x11, 0xb5, 0x1c, 0x7d, 0x33, 0x64,
> 0x47}}
> > > diff --git a/OvmfPkg/Include/Guid/LinuxEfiInitrdMedia.h b/MdePkg/Include/Guid/LinuxEfiInitrdMedia.h
> > > similarity index 100%
> > > rename from OvmfPkg/Include/Guid/LinuxEfiInitrdMedia.h
> > > rename to MdePkg/Include/Guid/LinuxEfiInitrdMedia.h
> > > --
> > > 2.25.1
> > >
> > >
> > >
> > >
> > >
> >
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [edk2-devel] [PATCH 1/1] MdePkg: add definition of LINUX_EFI_INITRD_MEDIA_GUID
2021-07-16 15:00 ` Michael D Kinney
@ 2021-07-16 15:56 ` Ard Biesheuvel
2021-07-20 16:59 ` Jeff Brasen
2021-07-21 8:16 ` Daniel Schaefer
0 siblings, 2 replies; 12+ messages in thread
From: Ard Biesheuvel @ 2021-07-16 15:56 UTC (permalink / raw)
To: Kinney, Michael D
Cc: Jeff Brasen, devel@edk2.groups.io, ardb+tianocore@kernel.org,
Justen, Jordan L, gaoliming@byosoft.com.cn, Liu, Zhiguang,
Samer El-Haj-Mahmoud
On Fri, 16 Jul 2021 at 17:00, Kinney, Michael D
<michael.d.kinney@intel.com> 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 candidate) 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.
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [edk2-devel] [PATCH 1/1] MdePkg: add definition of LINUX_EFI_INITRD_MEDIA_GUID
2021-07-16 15:56 ` Ard Biesheuvel
@ 2021-07-20 16:59 ` Jeff Brasen
2021-07-21 15:38 ` Michael D Kinney
2021-07-21 8:16 ` Daniel Schaefer
1 sibling, 1 reply; 12+ messages in thread
From: Jeff Brasen @ 2021-07-20 16:59 UTC (permalink / raw)
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
[-- Attachment #1: Type: text/plain, Size: 3351 bytes --]
In my opinion MdePkg is where this should be as it is meant to be used by multiple 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)
I am fine with MdeModulePkg as well though.
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@nvidia.com>; devel@edk2.groups.io <devel@edk2.groups.io>; ardb+tianocore@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 LINUX_EFI_INITRD_MEDIA_GUID
External email: Use caution opening links or attachments
On Fri, 16 Jul 2021 at 17:00, Kinney, Michael D
<michael.d.kinney@intel.com> 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 candidate) 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.
[-- Attachment #2: Type: text/html, Size: 4795 bytes --]
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [edk2-devel] [PATCH 1/1] MdePkg: add definition of LINUX_EFI_INITRD_MEDIA_GUID
2021-07-16 15:56 ` Ard Biesheuvel
2021-07-20 16:59 ` Jeff Brasen
@ 2021-07-21 8:16 ` Daniel Schaefer
1 sibling, 0 replies; 12+ messages in thread
From: Daniel Schaefer @ 2021-07-21 8:16 UTC (permalink / raw)
To: devel, ardb, Kinney, Michael D
Cc: Jeff Brasen, ardb+tianocore@kernel.org, Justen, Jordan L,
gaoliming@byosoft.com.cn, Liu, Zhiguang, Samer El-Haj-Mahmoud,
Abner Chang
On 7/16/21 11:56 PM, Ard Biesheuvel wrote:
> On Fri, 16 Jul 2021 at 17:00, Kinney, Michael D
> <michael.d.kinney@intel.com> 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 candidate) 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.
It's a good idea. We followed your advice and added your initrd command
to our development branch of RISC-V EDK2:
https://github.com/riscv/riscv-edk2-platforms/commit/534eeba0ac9b984eedc58ba1e8a2d28e2827ba40
And we're using it in our CI to test whether Linux boots:
https://github.com/riscv/riscv-edk2-platforms/blob/riscv-virt-gh-actions/.github/workflows/riscv-edk2.yml#L314
> 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.
>
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [edk2-devel] [PATCH 1/1] MdePkg: add definition of LINUX_EFI_INITRD_MEDIA_GUID
2021-07-20 16:59 ` Jeff Brasen
@ 2021-07-21 15:38 ` Michael D Kinney
2021-07-21 17:26 ` Jeff Brasen
0 siblings, 1 reply; 12+ messages in thread
From: Michael D Kinney @ 2021-07-21 15:38 UTC (permalink / raw)
To: Jeff Brasen, 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
[-- Attachment #1: Type: text/plain, Size: 5024 bytes --]
Hi Ard,
If this device path node is considered 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 usually try 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 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 appears to be incomplete. There is an OvmfPkg/Include/Guid/LinuxEfiInitrdMedia.h
file in the OvmfPkg. Shouldn’t 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 <michael.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, 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 LINUX_EFI_INITRD_MEDIA_GUID
In my opinion MdePkg is where this should be as it is meant to be used by multiple 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)
I am fine with MdeModulePkg as well though.
Thanks,
Jeff
________________________________
From: Ard Biesheuvel <ardb@kernel.org<mailto:ardb@kernel.org>>
Sent: Friday, July 16, 2021 9:56 AM
To: Kinney, Michael D <michael.d.kinney@intel.com<mailto:michael.d.kinney@intel.com>>
Cc: Jeff Brasen <jbrasen@nvidia.com<mailto:jbrasen@nvidia.com>>; devel@edk2.groups.io<mailto:devel@edk2.groups.io> <devel@edk2.groups.io<mailto:devel@edk2.groups.io>>; ardb+tianocore@kernel.org<mailto:ardb+tianocore@kernel.org> <ardb+tianocore@kernel.org<mailto:ardb+tianocore@kernel.org>>; Justen, Jordan L <jordan.l.justen@intel.com<mailto:jordan.l.justen@intel.com>>; gaoliming@byosoft.com.cn<mailto:gaoliming@byosoft.com.cn> <gaoliming@byosoft.com.cn<mailto:gaoliming@byosoft.com.cn>>; Liu, Zhiguang <zhiguang.liu@intel.com<mailto:zhiguang.liu@intel.com>>; Samer El-Haj-Mahmoud <Samer.El-Haj-Mahmoud@arm.com<mailto:Samer.El-Haj-Mahmoud@arm.com>>
Subject: Re: [edk2-devel] [PATCH 1/1] MdePkg: add definition of LINUX_EFI_INITRD_MEDIA_GUID
External email: Use caution opening links or attachments
On Fri, 16 Jul 2021 at 17:00, Kinney, Michael D
<michael.d.kinney@intel.com<mailto:michael.d.kinney@intel.com>> 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 candidate) 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.
[-- Attachment #2: Type: text/html, Size: 47912 bytes --]
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [edk2-devel] [PATCH 1/1] MdePkg: add definition of LINUX_EFI_INITRD_MEDIA_GUID
2021-07-21 15:38 ` Michael D Kinney
@ 2021-07-21 17:26 ` Jeff Brasen
2021-07-21 18:04 ` Michael D Kinney
0 siblings, 1 reply; 12+ messages in thread
From: Jeff Brasen @ 2021-07-21 17:26 UTC (permalink / raw)
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
[-- Attachment #1: Type: text/plain, Size: 6805 bytes --]
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 initrd file"
Also, the patch does have
{OvmfPkg => MdePkg}/Include/Guid/LinuxEfiInitrdMedia.h | 0
3 files changed, 5 insertions(+), 1 deletion(-)
rename {OvmfPkg => MdePkg}/Include/Guid/LinuxEfiInitrdMedia.h (100%)
[snip]
diff --git a/OvmfPkg/Include/Guid/LinuxEfiInitrdMedia.h b/MdePkg/Include/Guid/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 <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+tianocore@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 LINUX_EFI_INITRD_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 between the Linux kernel and
firmware, then it does make sense for it to be in the MdePkg. We usually try 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 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 appears to be incomplete. There is an OvmfPkg/Include/Guid/LinuxEfiInitrdMedia.h
file in the OvmfPkg. Shouldn’t 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 <michael.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, 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 LINUX_EFI_INITRD_MEDIA_GUID
In my opinion MdePkg is where this should be as it is meant to be used by multiple 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)
I am fine with MdeModulePkg as well though.
Thanks,
Jeff
________________________________
From: Ard Biesheuvel <ardb@kernel.org<mailto:ardb@kernel.org>>
Sent: Friday, July 16, 2021 9:56 AM
To: Kinney, Michael D <michael.d.kinney@intel.com<mailto:michael.d.kinney@intel.com>>
Cc: Jeff Brasen <jbrasen@nvidia.com<mailto:jbrasen@nvidia.com>>; devel@edk2.groups.io<mailto:devel@edk2.groups.io> <devel@edk2.groups.io<mailto:devel@edk2.groups.io>>; ardb+tianocore@kernel.org<mailto:ardb+tianocore@kernel.org> <ardb+tianocore@kernel.org<mailto:ardb+tianocore@kernel.org>>; Justen, Jordan L <jordan.l.justen@intel.com<mailto:jordan.l.justen@intel.com>>; gaoliming@byosoft.com.cn<mailto:gaoliming@byosoft.com.cn> <gaoliming@byosoft.com.cn<mailto:gaoliming@byosoft.com.cn>>; Liu, Zhiguang <zhiguang.liu@intel.com<mailto:zhiguang.liu@intel.com>>; Samer El-Haj-Mahmoud <Samer.El-Haj-Mahmoud@arm.com<mailto:Samer.El-Haj-Mahmoud@arm.com>>
Subject: Re: [edk2-devel] [PATCH 1/1] MdePkg: add definition of LINUX_EFI_INITRD_MEDIA_GUID
External email: Use caution opening links or attachments
On Fri, 16 Jul 2021 at 17:00, Kinney, Michael D
<michael.d.kinney@intel.com<mailto:michael.d.kinney@intel.com>> 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 candidate) 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.
[-- Attachment #2: Type: text/html, Size: 17982 bytes --]
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [edk2-devel] [PATCH 1/1] MdePkg: add definition of LINUX_EFI_INITRD_MEDIA_GUID
2021-07-21 17:26 ` Jeff Brasen
@ 2021-07-21 18:04 ` Michael D Kinney
2021-07-22 9:56 ` Ard Biesheuvel
0 siblings, 1 reply; 12+ messages in thread
From: Michael D Kinney @ 2021-07-21 18:04 UTC (permalink / raw)
To: Jeff Brasen, 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
[-- Attachment #1: Type: text/plain, Size: 8886 bytes --]
Hi Jeff,
I see. I missed the file rename line in the git patch.
I think the description needs to be expanded to clearly describe the production and consumption of this device path with this GUID.
1. What component creates the UEFI handle with the Device Path Protocol and the LoadFile2 Protocol with the initrd image? Is it the platform FW or the OS Loader? If it is the platform FW, then how does the platform FW know which initrd image to publish if there are multiple Linux OSes installed?
2. What component locates the UEFI handle with the Device Path Protocol and the LoadFile2 Protocol with the initrd image? It is another stage of the OS Loader or the OS Kernel? Given that these handles are only available before ExitBootServices, I think this means that the component that locates the initrd image has to do so before ExitBootServices is called.
Thanks,
Mike
From: Jeff Brasen <jbrasen@nvidia.com>
Sent: Wednesday, July 21, 2021 10:26 AM
To: Kinney, Michael D <michael.d.kinney@intel.com>; Ard Biesheuvel <ardb@kernel.org>
Cc: devel@edk2.groups.io; ardb+tianocore@kernel.org; Justen, Jordan L <jordan.l.justen@intel.com>; 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 LINUX_EFI_INITRD_MEDIA_GUID
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 initrd file"
Also, the patch does have
{OvmfPkg => MdePkg}/Include/Guid/LinuxEfiInitrdMedia.h | 0
3 files changed, 5 insertions(+), 1 deletion(-)
rename {OvmfPkg => MdePkg}/Include/Guid/LinuxEfiInitrdMedia.h (100%)
[snip]
diff --git a/OvmfPkg/Include/Guid/LinuxEfiInitrdMedia.h b/MdePkg/Include/Guid/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 <michael.d.kinney@intel.com<mailto:michael.d.kinney@intel.com>>
Sent: Wednesday, July 21, 2021 9:38 AM
To: Jeff Brasen <jbrasen@nvidia.com<mailto:jbrasen@nvidia.com>>; Ard Biesheuvel <ardb@kernel.org<mailto:ardb@kernel.org>>; Kinney, Michael D <michael.d.kinney@intel.com<mailto:michael.d.kinney@intel.com>>
Cc: devel@edk2.groups.io<mailto:devel@edk2.groups.io> <devel@edk2.groups.io<mailto:devel@edk2.groups.io>>; ardb+tianocore@kernel.org<mailto:ardb+tianocore@kernel.org> <ardb+tianocore@kernel.org<mailto:ardb+tianocore@kernel.org>>; Justen, Jordan L <jordan.l.justen@intel.com<mailto:jordan.l.justen@intel.com>>; gaoliming@byosoft.com.cn<mailto:gaoliming@byosoft.com.cn> <gaoliming@byosoft.com.cn<mailto:gaoliming@byosoft.com.cn>>; Liu, Zhiguang <zhiguang.liu@intel.com<mailto:zhiguang.liu@intel.com>>; Samer El-Haj-Mahmoud <Samer.El-Haj-Mahmoud@arm.com<mailto:Samer.El-Haj-Mahmoud@arm.com>>
Subject: RE: [edk2-devel] [PATCH 1/1] MdePkg: add definition of LINUX_EFI_INITRD_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 between the Linux kernel and
firmware, then it does make sense for it to be in the MdePkg. We usually try 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 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 appears to be incomplete. There is an OvmfPkg/Include/Guid/LinuxEfiInitrdMedia.h
file in the OvmfPkg. Shouldn’t that file also be moved to the MdePkg as part of this patch?
Thanks,
Mike
From: Jeff Brasen <jbrasen@nvidia.com<mailto:jbrasen@nvidia.com>>
Sent: Tuesday, July 20, 2021 9:59 AM
To: Ard Biesheuvel <ardb@kernel.org<mailto:ardb@kernel.org>>; Kinney, Michael D <michael.d.kinney@intel.com<mailto:michael.d.kinney@intel.com>>
Cc: devel@edk2.groups.io<mailto:devel@edk2.groups.io>; ardb+tianocore@kernel.org<mailto:ardb+tianocore@kernel.org>; Justen, Jordan L <jordan.l.justen@intel.com<mailto:jordan.l.justen@intel.com>>; gaoliming@byosoft.com.cn<mailto:gaoliming@byosoft.com.cn>; Liu, Zhiguang <zhiguang.liu@intel.com<mailto:zhiguang.liu@intel.com>>; Samer El-Haj-Mahmoud <Samer.El-Haj-Mahmoud@arm.com<mailto:Samer.El-Haj-Mahmoud@arm.com>>
Subject: Re: [edk2-devel] [PATCH 1/1] MdePkg: add definition of LINUX_EFI_INITRD_MEDIA_GUID
In my opinion MdePkg is where this should be as it is meant to be used by multiple 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)
I am fine with MdeModulePkg as well though.
Thanks,
Jeff
________________________________
From: Ard Biesheuvel <ardb@kernel.org<mailto:ardb@kernel.org>>
Sent: Friday, July 16, 2021 9:56 AM
To: Kinney, Michael D <michael.d.kinney@intel.com<mailto:michael.d.kinney@intel.com>>
Cc: Jeff Brasen <jbrasen@nvidia.com<mailto:jbrasen@nvidia.com>>; devel@edk2.groups.io<mailto:devel@edk2.groups.io> <devel@edk2.groups.io<mailto:devel@edk2.groups.io>>; ardb+tianocore@kernel.org<mailto:ardb+tianocore@kernel.org> <ardb+tianocore@kernel.org<mailto:ardb+tianocore@kernel.org>>; Justen, Jordan L <jordan.l.justen@intel.com<mailto:jordan.l.justen@intel.com>>; gaoliming@byosoft.com.cn<mailto:gaoliming@byosoft.com.cn> <gaoliming@byosoft.com.cn<mailto:gaoliming@byosoft.com.cn>>; Liu, Zhiguang <zhiguang.liu@intel.com<mailto:zhiguang.liu@intel.com>>; Samer El-Haj-Mahmoud <Samer.El-Haj-Mahmoud@arm.com<mailto:Samer.El-Haj-Mahmoud@arm.com>>
Subject: Re: [edk2-devel] [PATCH 1/1] MdePkg: add definition of LINUX_EFI_INITRD_MEDIA_GUID
External email: Use caution opening links or attachments
On Fri, 16 Jul 2021 at 17:00, Kinney, Michael D
<michael.d.kinney@intel.com<mailto:michael.d.kinney@intel.com>> 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 candidate) 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.
[-- Attachment #2: Type: text/html, Size: 61046 bytes --]
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [edk2-devel] [PATCH 1/1] MdePkg: add definition of LINUX_EFI_INITRD_MEDIA_GUID
2021-07-21 18:04 ` Michael D Kinney
@ 2021-07-22 9:56 ` Ard Biesheuvel
0 siblings, 0 replies; 12+ messages in thread
From: Ard Biesheuvel @ 2021-07-22 9:56 UTC (permalink / raw)
To: Kinney, Michael D
Cc: Jeff Brasen, devel@edk2.groups.io, ardb+tianocore@kernel.org,
Justen, Jordan L, gaoliming@byosoft.com.cn, Liu, Zhiguang,
Samer El-Haj-Mahmoud
[-- Attachment #1: Type: text/plain, Size: 9608 bytes --]
On Wed, 21 Jul 2021 at 20:04, Kinney, Michael D <michael.d.kinney@intel.com>
wrote:
> Hi Jeff,
>
>
>
> I see. I missed the file rename line in the git patch.
>
>
>
> I think the description needs to be expanded to clearly describe the
> production and consumption of this device path with this GUID.
>
>
>
> 1. What component creates the UEFI handle with the Device Path
> Protocol and the LoadFile2 Protocol with the initrd image? Is it the
> platform FW or the OS Loader? If it is the platform FW, then how does
> the platform FW know which initrd image to publish if there are
> multiple Linux OSes installed?
>
>
This is really the firmware/loader's problem. In the ARM / RISC-V world,
the distinction between firmware and pre-OS loader is not as clear cut, and
for instance, U-boot in EFI mode can either boot the kernel directly (and
expose the initrd via this method), or invoke GRUB as an EFI app using
LoadImage/StartImage, in which case GRUB can load the kernel and/or initrd
via whichever interface it desires.
It is therefore also the platform FW's problem to decide which initrd goes
with which kernel - it is highly platform dependent whether a certain
initrd is compatible with only a single kernel, or can be combined with any
kernel (e.g., when the kernel has all drivers builtin, and the initrd only
contains the user space)
>
> 1.
> 2. What component locates the UEFI handle with the Device Path
> Protocol and the LoadFile2 Protocol with the initrd image? It is
> another stage of the OS Loader or the OS Kernel? Given that these
> handles are only available before ExitBootServices, I think this means
> that the component that locates the initrd image has to do so before
> ExitBootServices is called.
>
>
>
The consumer of the protocol is the EFI stub loader in Linux, i.e., the OS
loader that is built into the OS kernel. It is the agent that calls
ExitBootServices(), and it indeed consumes the protocol beforehand.
In summary, I think it should be sufficient to describe the consumer's
expectations with respect to the API. I don't think it makes sense to be
normative about how platform firmware or intermediate loaders keep track of
which file to expose, as long as it complies with the consumer's
requirements.
> *To:* Kinney, Michael D <michael.d.kinney@intel.com>; Ard Biesheuvel <
> ardb@kernel.org>
> *Cc:* devel@edk2.groups.io; ardb+tianocore@kernel.org; Justen, Jordan L <
> jordan.l.justen@intel.com>; 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
> LINUX_EFI_INITRD_MEDIA_GUID
>
>
>
> 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
> initrd file"
>
>
>
>
>
> Also, the patch does have
>
> {OvmfPkg => MdePkg}/Include/Guid/LinuxEfiInitrdMedia.h | 0
> 3 files changed, 5 insertions(+), 1 deletion(-)
> rename {OvmfPkg => MdePkg}/Include/Guid/LinuxEfiInitrdMedia.h (100%)
> [snip]
> diff --git a/OvmfPkg/Include/Guid/LinuxEfiInitrdMedia.h
> b/MdePkg/Include/Guid/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 <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+tianocore@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
> LINUX_EFI_INITRD_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
> between the Linux kernel and
>
> firmware, then it does make sense for it to be in the MdePkg. We usually
> try 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
> 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 appears to be incomplete. There is an OvmfPkg
> /Include/Guid/LinuxEfiInitrdMedia.h
>
> file in the OvmfPkg. Shouldn’t 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 <
> michael.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, 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
> LINUX_EFI_INITRD_MEDIA_GUID
>
>
>
> In my opinion MdePkg is where this should be as it is meant to be used by
> multiple 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)
>
>
>
> I am fine with MdeModulePkg as well though.
>
>
>
> 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@nvidia.com>; devel@edk2.groups.io <
> devel@edk2.groups.io>; ardb+tianocore@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
> LINUX_EFI_INITRD_MEDIA_GUID
>
>
>
> External email: Use caution opening links or attachments
>
>
> On Fri, 16 Jul 2021 at 17:00, Kinney, Michael D
> <michael.d.kinney@intel.com> 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
> candidate) 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.
>
[-- Attachment #2: Type: text/html, Size: 21079 bytes --]
^ permalink raw reply [flat|nested] 12+ messages in thread
end of thread, other threads:[~2021-07-22 9:57 UTC | newest]
Thread overview: 12+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2021-07-15 18:07 [PATCH 1/1] MdePkg: add definition of LINUX_EFI_INITRD_MEDIA_GUID Jeff Brasen
2021-07-15 22:56 ` [edk2-devel] " Michael D Kinney
2021-07-15 23:20 ` Jeff Brasen
2021-07-16 12:09 ` Ard Biesheuvel
2021-07-16 15:00 ` Michael D Kinney
2021-07-16 15:56 ` Ard Biesheuvel
2021-07-20 16:59 ` Jeff Brasen
2021-07-21 15:38 ` Michael D Kinney
2021-07-21 17:26 ` Jeff Brasen
2021-07-21 18:04 ` Michael D Kinney
2021-07-22 9:56 ` Ard Biesheuvel
2021-07-21 8:16 ` Daniel Schaefer
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox