From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-12.3 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_CR_TRAILER, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 07347C433DB for ; Mon, 15 Mar 2021 03:12:16 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id C389764E98 for ; Mon, 15 Mar 2021 03:12:15 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229825AbhCODLo (ORCPT ); Sun, 14 Mar 2021 23:11:44 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:46444 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229909AbhCODL0 (ORCPT ); Sun, 14 Mar 2021 23:11:26 -0400 Received: from mail-pf1-x433.google.com (mail-pf1-x433.google.com [IPv6:2607:f8b0:4864:20::433]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 3D17AC061574 for ; Sun, 14 Mar 2021 20:11:26 -0700 (PDT) Received: by mail-pf1-x433.google.com with SMTP id 16so5703272pfn.5 for ; Sun, 14 Mar 2021 20:11:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=4Bt99tj/N3eDjWBiir4ht9YpU27QxmIKuYPd5FFn+AU=; b=WzpLpc5dVQUIFRnmTTbiK324+TNUk68pdDqAP1k2L1CX4JE7S0QCYnSgNZ58YuiOp+ Z4+ZkfzaYqeJZf3H0XvOIw0ELChRugpel0DZVuORypfPnMH4+rqgTGSqOqoX39QU7EHp bEy3v48Ch4sIAZ+3t/c8iYvg/BSbCVXU8jhnhcCgYGS/WaCGlV5qSOMHbZdzoygS7ObD nzBde7yQQk4X1FGkhnop+RmZA9GIVHDmgTQwMtMyEg2fnRMg+1CB7B1h1OGSe0ibo5pQ dPdUKQ+HHyCurS+LGfIWW1mesOCNSZttdhdt1s8n8G+p4uh7sLdBEsjZp6DqPAkCqROW sN2Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=4Bt99tj/N3eDjWBiir4ht9YpU27QxmIKuYPd5FFn+AU=; b=HCgl/Aq+sTZxxZtcWkm9m6SGwQZQ/Y0SR9tOSsRSq7FfxYiAB6Php4Z8OqGxsXIpba GsutDZ1l3K30/QMQ0gvX9R6w0zk/BZypugMbtV1Ud/azv5fQvmVLc8CG9uCshV+LWr/X +hNMxBmegrlfsWWklUN9fA5C7df8ygVncrR0hpT7sVB+eH2yud98rPx9mlPWz4tDdZzY tc9Zc2hfaaosrB0wInIAM7vJQE96sQBRsOZjoKXlSdcTa2Q483+ev3YMkNzSTlNiUjFW eAr3kH+sLjX5p47EIGLZV8LYiHDXQDlZbkpoiCujkbtgN+h3RY2I1cUCueRZ/Dw9bIPm iDew== X-Gm-Message-State: AOAM530CQAN08dzZnGAJVxrRj3EEgs9UhnfJq7uc1tOpeA9x9pC+NrNR 2VwyqjscyO0HxAPZng85S8u7dg== X-Google-Smtp-Source: ABdhPJx5WIgYFkRCN97yHAyDkpMvugKGPrl8et8ihthtKspSKYBOeah55d9KchYqCDT9bNh5rKdJXg== X-Received: by 2002:aa7:991a:0:b029:201:b736:c556 with SMTP id z26-20020aa7991a0000b0290201b736c556mr8397757pff.8.1615777885718; Sun, 14 Mar 2021 20:11:25 -0700 (PDT) Received: from dragon (80.251.214.228.16clouds.com. [80.251.214.228]) by smtp.gmail.com with ESMTPSA id g26sm11568634pge.67.2021.03.14.20.11.23 (version=TLS1_2 cipher=ECDHE-ECDSA-CHACHA20-POLY1305 bits=256/256); Sun, 14 Mar 2021 20:11:25 -0700 (PDT) Date: Mon, 15 Mar 2021 11:11:19 +0800 From: Shawn Guo To: Ard Biesheuvel Cc: Rob Clark , linux-efi , Jeffrey Hugo , Bjorn Andersson , Leif Lindholm , linux-arm-msm Subject: Re: [PATCH] efi: stub: override RT_PROP table supported mask based on EFI variable Message-ID: <20210315031119.GY17424@dragon> References: <20210306113519.294287-1-ardb@kernel.org> <20210307110228.GP17424@dragon> <20210309032248.GR17424@dragon> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.9.4 (2018-02-28) Precedence: bulk List-ID: X-Mailing-List: linux-arm-msm@vger.kernel.org On Tue, Mar 09, 2021 at 07:47:25PM +0100, Ard Biesheuvel wrote: > On Tue, 9 Mar 2021 at 19:10, Rob Clark wrote: > > > > On Mon, Mar 8, 2021 at 7:22 PM Shawn Guo wrote: > > > > > > On Mon, Mar 08, 2021 at 02:34:48PM +0100, Ard Biesheuvel wrote: > > > > On Sun, 7 Mar 2021 at 12:02, Shawn Guo wrote: > > > > > > > > > > On Sat, Mar 06, 2021 at 12:35:19PM +0100, Ard Biesheuvel wrote: > > > > > > Allow EFI systems to override the set of supported runtime services > > > > > > declared via the RT_PROP table, by checking for the existence of a > > > > > > 'OverrideSupported' EFI variable of the appropriate size under the > > > > > > RT_PROP table GUID, and if it does, combine the supported mask using > > > > > > logical AND. (This means the override can only remove support, not > > > > > > add it back). > > > > > > > > > > > > Cc: Jeffrey Hugo , > > > > > > Cc: Bjorn Andersson > > > > > > Cc: Shawn Guo > > > > > > Cc: Rob Clark > > > > > > Cc: Leif Lindholm > > > > > > Cc: linux-arm-msm@vger.kernel.org > > > > > > > > > > > > Signed-off-by: Ard Biesheuvel > > > > > > > > > > Awesome, Ard! On both Lenovo Yoga C630 and Flex 5G latops: > > > > > > > > > > Tested-by: Shawn Guo > > > > > > > > > > With 'OverrideSupported' EFI variable added from UEFI Shell, we can drop > > > > > 'efi=novamap' kernel cmdline and get around the broken poweroff runtime > > > > > services nicely. Thanks! > > > > > > > > > > > > > Thanks for confirming. > > > > > > > > However, I am not going to merge this without some justification, and > > > > hopefully some input from other folks (Leif?) > > > > > > > > RTPROP already provides what we need on all platforms that use > > > > DtbLoader, and the patch for that is queued up for v5.12-rcX, with a > > > > cc:stable to v5.10. This allows any RT service to be marked as > > > > disabled, including SetVirtualAddressMap(). > > > > > > > > So afaict, that means that this patch would be a special case for > > > > Flex5G, right? > > > > > > It's for all Snapdragon based laptops, as we need to disable > > > SetVirtualAddressMap runtime services on all of them. > > > > > > > So how are platforms such as this one going to load the > > > > DTB? If some loader will be involved (or even just GRUB), > > > > > > Yes, GRUB. > > > > > > > shouldn't it > > > > be that component that sets RTPROP like DtbLoader will, not the kernel > > > > itself. > > > > > > > > Btw I don't think ACPI boot is a use case here. I don't see a software > > > > framebuffer with no wifi support as a usage mode that justifies > > > > carrying EFI stub hacks for everyone. > > > > > > Okay. I'm fine to carry it as an out-of-tree patch until someday you > > > consider ACPI boot is useful for everyone. But I do boot these laptops > > > with ACPI at daily basis right now as arm64 native build machine, with > > > USB Ethernet adapter. > > > > fwiw, the valid use-case for ACPI boot on these things is for distro > > installer.. it might not be the shiny accelerated experience, but you > > want to be able to get thru the installer and then install updates to > > get latest kernel/dtb/etc > > > > it is a small use-case, but kinda an important step ;-) > > > > That is a fair point. However, as I understand it, we need this to work around > - the need to pass efi=novamap > - broken poweroff on Flex5g One more: broken EFI variable runtime services on all Snapdragon laptops It's been another pain of running debian-installer (d-i) on these laptops, where EFI NV variables are just stored on UFS disk. So after Linux takes over the control of UFS, EFI NV variable runtime services then become out of service. Currently, we have to apply a hack [1] on d-i grub-installer to get around the issue, and it's been the only remaining out-of-tree patch we have to carry for d-i. With this nice `OverrideSupported` support, we will be able to drop that hack completely. > > So an installer either needs to set the EFI variable, or pass > efi=novamap on the first boot. Note that there are no arm64 EFI > systems known where efi=novamap causes problems. In fact, I would > prefer to stop using SetVirtualAddressMap() altogether, as it does not > provide any benefit whatsoever. So perhaps we should make efi=novamap > the default and be done with it. > > Broken poweroff is hardly a showstopper for an installer, given that > we cannot even install GRUB correctly. > > In summary, I am more than happy to collaborate constructively on this > (which is why I wrote the patch), but I don't think we're at a point > yet where this is the only thing standing in our way when it comes to > a smooth out-of-the-box Linux installation experience. There might be more to be done for getting a smooth Linux installation experience. But IMHO, this `OverrideSupported` thing is definitely a big step to that. Shawn [1] https://salsa.debian.org/installer-team/grub-installer/-/merge_requests/5