From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail02.groups.io (mail02.groups.io [66.175.222.108]) by spool.mail.gandi.net (Postfix) with ESMTPS id 507F4740054 for ; Tue, 16 Jan 2024 06:05:02 +0000 (UTC) DKIM-Signature: a=rsa-sha256; bh=d2E/TunmSaM500r+sOvUYC6o/bl+iuGziTWWpMgwkyc=; c=relaxed/simple; d=groups.io; h=MIME-Version:References:In-Reply-To:From:Date:Message-ID:Subject:To:Cc:Precedence:List-Subscribe:List-Help:Sender:List-Id:Mailing-List:Delivered-To:Reply-To:List-Unsubscribe-Post:List-Unsubscribe:Content-Type:Content-Transfer-Encoding; s=20140610; t=1705385101; v=1; b=hoZWu9PGEPfGEgUvkUIsk67DJ523K2KRYr/hfHhx7flZS5OFVIRhhWPwh3n0sz2f/n6Qq59B Ix44Nx4I3ofYxquD4RBZxRs7AmOknoeSpzk2Rw3JXUYq8sS4qriCUIb4PzLJeaFtfkJArHYWuEh HIjK4dycJFewjNqp6HeQkcDM= X-Received: by 127.0.0.2 with SMTP id whJ9YY7687511xrqsaru6VCn; Mon, 15 Jan 2024 22:05:01 -0800 X-Received: from ams.source.kernel.org (ams.source.kernel.org [145.40.68.75]) by mx.groups.io with SMTP id smtpd.web10.80928.1705327500133167663 for ; Mon, 15 Jan 2024 06:05:00 -0800 X-Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by ams.source.kernel.org (Postfix) with ESMTP id DBC2CB80BE8 for ; Mon, 15 Jan 2024 14:04:57 +0000 (UTC) X-Received: by smtp.kernel.org (Postfix) with ESMTPSA id 409C7C43390 for ; Mon, 15 Jan 2024 14:04:57 +0000 (UTC) X-Received: by mail-lf1-f51.google.com with SMTP id 2adb3069b0e04-50eabfac2b7so10146576e87.0 for ; Mon, 15 Jan 2024 06:04:57 -0800 (PST) X-Gm-Message-State: Pf9N98NONzOFJi0VUsmf2t6yx7686176AA= X-Google-Smtp-Source: AGHT+IF1fDC96BIegs0IkYV9WLSlQJWtGj71C1JUWWqIH+sRRITCwPpH3em9NA2JtYzpWuxVTfZ/NHSgIfuan/k+1LY= X-Received: by 2002:a05:6512:2256:b0:50e:e168:9fcd with SMTP id i22-20020a056512225600b0050ee1689fcdmr3041505lfu.26.1705327495433; Mon, 15 Jan 2024 06:04:55 -0800 (PST) MIME-Version: 1.0 References: <44ca139f-4d78-4322-b5b6-8e9788bb7486@os.amperecomputing.com> <2ad16043-754e-3bb9-3a4a-702d9a50bf63@redhat.com> <45b95719-f1fc-dbc6-a4cc-a022d691844c@redhat.com> <8d745268-263c-c99a-67c6-fe0fb6cd4b8e@redhat.com> <0e0b2e56-30dd-4f5f-9708-98690246efda@os.amperecomputing.com> In-Reply-To: <0e0b2e56-30dd-4f5f-9708-98690246efda@os.amperecomputing.com> From: "Ard Biesheuvel" Date: Mon, 15 Jan 2024 15:04:43 +0100 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [edk2-devel] Memory Attribute for depex section To: Nhi Pham Cc: Laszlo Ersek , "Andrew (EFI) Fish" , edk2-devel-groups-io , "ardb+tianocore@kernel.org" Precedence: Bulk List-Subscribe: List-Help: Sender: devel@edk2.groups.io List-Id: Mailing-List: list devel@edk2.groups.io; contact devel+owner@edk2.groups.io Reply-To: devel@edk2.groups.io,ardb@kernel.org List-Unsubscribe-Post: List-Unsubscribe=One-Click List-Unsubscribe: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-GND-Status: LEGIT Authentication-Results: spool.mail.gandi.net; dkim=pass header.d=groups.io header.s=20140610 header.b=hoZWu9PG; dmarc=fail reason="SPF not aligned (relaxed), DKIM not aligned (relaxed)" header.from=kernel.org (policy=none); spf=pass (spool.mail.gandi.net: domain of bounce@groups.io designates 66.175.222.108 as permitted sender) smtp.mailfrom=bounce@groups.io On Mon, 15 Jan 2024 at 14:07, Nhi Pham wrote: > > On 1/12/2024 4:45 PM, Laszlo Ersek wrote: > > (Independently: I think that's a valid thing to do for *SMM* drivers, > > because the entry point functions of those drivers are permitted to use > > both SMM and DXE/UEFI protocols. But whether the same is valid for the > > *standalone* MM drivers -- that looks questionable. Standalone MM > > drivers should not depend on UEFI/DXE protocols ever, IIUC.) > > > >> 3) The issue is patching the grammar in place, why can=E2=80=99t we ju= st make a > >> copy for the dispatcher grammer, and operate on the copy. Maybe via a > >> copy on 1st update strategy? > > > > Yes, copying the depex to the heap, and patching it there, was Nhi's #1 > > fix proposal. I think that could be made work. But I'm not sure if the > > perf savings are worth the additional complexity. The heap allocation > > (where the writeable depex would exist) would have to be permanently > > associated with the loaded PE image -- because the dispatcher might nee= d > > to reevaluate the depex across multiple rounds of dispatching. So that'= s > > a new field in some image-related structure, it also needs to be freed > > upon unload (?), what if the memory allocation fails during depex eval > > (just consider the depex to eval to FALSE?), etc. Doable, but hairy; no= t > > sure if the perf is worth that effort. > > > > Thanks so much, Laszlo for your valuable insights. > > The approach #1 works for me. I will do further check for your concerns > above. > > I'm trying your suggested patch and investigating the performance being > discussed here. > Not sure what approach #1 means, but I'd prefer to just remove this optimization from standalone MM, given that not only a) it shouldn't have to deal with a large number of protocol GUIDs, but also b) the driver dispatch is much more straight-forward. (Typically, StMM drivers can be dispatched in the order they appear in the firmware volume, in which case each DEPEX is evaluated only once anyway) -=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#113822): https://edk2.groups.io/g/devel/message/113822 Mute This Topic: https://groups.io/mt/103594587/7686176 Group Owner: devel+owner@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [rebecca@openfw.io] -=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-