From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by mx.groups.io with SMTP id smtpd.web11.29320.1676326040357411619 for ; Mon, 13 Feb 2023 14:07:20 -0800 Authentication-Results: mx.groups.io; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=cdFXXhbG; spf=pass (domain: kernel.org, ip: 139.178.84.217, mailfrom: ardb@kernel.org) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id C4CF06130B for ; Mon, 13 Feb 2023 22:07:19 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 364B9C433EF for ; Mon, 13 Feb 2023 22:07:19 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1676326039; bh=41rRDbOtjyWD+axZ3IBx2sdT29oKPNLauWm3uBjCn28=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=cdFXXhbGkHyhwtkl4l054FpkelwfHckxCxYSxhBqKKbNuDzQ37FfWVPI3VG4OPs2U T0gE7QMMYQMsXJTc8aU6q2TikPVsKXqBJa/jUbt7M/yuscXUTI1cw5nq4MBja+0a81 7b0987g288ch3q4k0ky9u/6Qdmgoa2bFp1ZLQt07iaydpqgI4bKaC8BhmAbE3cP8Nj WU3nKIXVC22UB1sokRquR1OGUwwhcCvODuTmq1oHN02lmHMBRL28/KoT1lgSeh+KV0 9YK4ZIY2jy5xZG+TJHH9hlPrneECPRtgh70CBxvjAGtDFIATv/XYd9C6Zb3vJoslRB TwJW0ylnMGMuQ== Received: by mail-lf1-f51.google.com with SMTP id br9so20923188lfb.4 for ; Mon, 13 Feb 2023 14:07:19 -0800 (PST) X-Gm-Message-State: AO0yUKVWsxX5t7eGZxisTA7/3GE69vjhCFHF4ZQAvCV6FxCxK+Nt4FV6 0xdjo63yFKRsOu+IBTBFwtw15zoVYw6A6sfyILE= X-Google-Smtp-Source: AK7set+70XnKaZ4nCzxJr39I36paO40CmwqPxPhMTFn9MOEBx7RjYBsgduogcG2uNLNyQL61FnYsmwjofHFB0kQp2xw= X-Received: by 2002:a05:6512:41a:b0:4db:2ac3:a51a with SMTP id u26-20020a056512041a00b004db2ac3a51amr1631997lfk.29.1676326037167; Mon, 13 Feb 2023 14:07:17 -0800 (PST) MIME-Version: 1.0 References: <20230213151810.2301480-8-ardb@kernel.org> <18425.1676323948912560575@groups.io> In-Reply-To: <18425.1676323948912560575@groups.io> From: "Ard Biesheuvel" Date: Mon, 13 Feb 2023 23:07:05 +0100 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [edk2-devel] [RFC 07/13] MdeModulePkg/DxeCore: Permit preliminary CPU arch fallback To: =?UTF-8?Q?Marvin_H=C3=A4user?= Cc: devel@edk2.groups.io Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, 13 Feb 2023 at 22:32, Marvin H=C3=A4user wrote= : > > Without wanting to blow up your RFC with another one - I discussed this w= ith various people, including Bret when he was still at Project Mu, and the= re was a consensus among them that integrating the whole CPU arch code righ= t into DxeCore would be a good idea. This would especially remove the hack = that queues permission applications till CpuDxe loads for good, rather than= requiring pro-active consumption of a library that proves this "fallback".= For most of the architectural protocols, especially SecurityStubDxe, I nev= er got the gist why you would want them to be separate from DxeCore. Obviou= sly there should be a level of customizability for IBVs and OEMs, though th= at can be done statically-linked as well. > > REF: https://bugzilla.tianocore.org/show_bug.cgi?id=3D3223 > > What's your take on this? > My take is that page table manipulation should not be part of the CPU arch protocol. The DXE core loads images and dispatches them, which also involves cache maintenance, for instance, as code pages need to be invalidated from the I-cache before you can execute a newly loaded image. I think it makes perfect sense for the DXE core to be in charge of updating the page table descriptors as well. In my approach, the library version is only used before the CPU arch protocol appears, so it addresses some of the concerns regarding multiple owners. But I'd prefer to see this removed from the CPU arch protocol entirely, or at least for the CPU arch protocol interface to be deprecated, and redefined in terms of a new DXE services, for instance, that is implemented by the DXE core itself. That way, all existing users would still see the same protocols, but the way they depend on each other would be inverted.