From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by mx.groups.io with SMTP id smtpd.web09.8595.1626451001007338815 for ; Fri, 16 Jul 2021 08:56:41 -0700 Authentication-Results: mx.groups.io; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=aigvIe80; spf=pass (domain: kernel.org, ip: 198.145.29.99, mailfrom: ardb@kernel.org) Received: by mail.kernel.org (Postfix) with ESMTPSA id 45A4661164 for ; Fri, 16 Jul 2021 15:56:40 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1626451000; bh=GXP33Xmh9L1gAYWXtNLT/TQCq70jMtfIKYJ0n24+gCI=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=aigvIe80PyyCrl8An0USGiq6GynC/2M5XAWYBPGWRigW+tDjJs50hU3U1/+UMtZwC h1oVHcPKZG0U9rqiPOKhFMIhQwkwNQEjW+ay3ZHmFT/p627ngHVgNfeXafEZNvAcg1 6ArpUTPkSp42Umc84d+790691DeY6rpE6X/Deim50yDWF68QbJ0glXR8BKZ3/Vfl84 gh4N287WMLSnuKIjjVy6xut9aH8nJH697+s3cQ1KvtoKDdyZ0GGroxOTzp9ca1c3fH N8r1weUm95bh1eVyBFeiLhIgLFNYYS5mxizu/Eflo+pfvKeCwUI+tzcBxkPeX2ZkQq 9fVWTlLI4Bd6g== Received: by mail-oi1-f173.google.com with SMTP id h9so11421010oih.4 for ; Fri, 16 Jul 2021 08:56:40 -0700 (PDT) X-Gm-Message-State: AOAM533OtzVG1I5PaqWHhlDFF7b1g1xwdZbgjtBOhsVqrqn7RheKuVXs hyJ2CM4iXyA3sJ6GRPtuBHDCiC97aaRkadCMm1M= X-Google-Smtp-Source: ABdhPJxblBQNdOrbsmttlBrAElfxznQgikl52ONhm43ry9/+wNIYlavkwdmitLwuv9AAvcTCbhQSg6bdUFdW+K+rdM0= X-Received: by 2002:aca:4c49:: with SMTP id z70mr8247743oia.174.1626450999613; Fri, 16 Jul 2021 08:56:39 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: "Ard Biesheuvel" Date: Fri, 16 Jul 2021 17:56:28 +0200 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [edk2-devel] [PATCH 1/1] MdePkg: add definition of LINUX_EFI_INITRD_MEDIA_GUID 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 Content-Type: text/plain; charset="UTF-8" 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 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.