From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mout02.posteo.de (mout02.posteo.de [185.67.36.66]) by mx.groups.io with SMTP id smtpd.web10.29504.1676327086628561800 for ; Mon, 13 Feb 2023 14:24:46 -0800 Authentication-Results: mx.groups.io; dkim=pass header.i=@posteo.de header.s=2017 header.b=hJWcw2OS; spf=pass (domain: posteo.de, ip: 185.67.36.66, mailfrom: mhaeuser@posteo.de) Received: from submission (posteo.de [185.67.36.169]) by mout02.posteo.de (Postfix) with ESMTPS id DE03124032F for ; Mon, 13 Feb 2023 23:24:44 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.de; s=2017; t=1676327084; bh=4kKQ6pMeJdp6eHPTyU1ITSk2SwVheBAhF9haBEOMcU4=; h=Subject:From:Date:Cc:To:From; b=hJWcw2OSrbhTXlqGyYF2MUnWpH1dq6FSHH0UVp/N+yFZvW1VKfwNf0alcylQWanhm GQ/aK4K1ah3tLjlMZhTbqy9jP3R7Alnjlx3+zqMWbNqKuRnY98HEWIamF0BkslO+mG tnghn3zGNTs+C8Fx1wUvM9OUhW4sZLfMfipG8lpXthQfem4UFE0CLkzNu9Dflsnucw qHbgKEld4H+3IIazGfPg5GMthj2xnCgc7Cy5fO6Dc5mVhVeUal7T+d0ljLUeQw69Ey kDPQX3/8of3DXEE2S0Z+hq7nj6CmqFLfE23h3HU5igK90/Rmmyhf5ym7FLE5NArkZK 7ac0RQwseZxlA== Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4PFzRJ0tvWz9rxD; Mon, 13 Feb 2023 23:24:44 +0100 (CET) Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3731.400.51.1.1\)) Subject: Re: [edk2-devel] [RFC 07/13] MdeModulePkg/DxeCore: Permit preliminary CPU arch fallback From: =?UTF-8?B?TWFydmluIEjDpHVzZXI=?= In-Reply-To: Date: Mon, 13 Feb 2023 22:24:33 +0000 Cc: devel@edk2.groups.io Message-Id: References: <20230213151810.2301480-8-ardb@kernel.org> <18425.1676323948912560575@groups.io> To: Ard Biesheuvel Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Sounds good to me, thanks! Best regards, Marvin > On 13. Feb 2023, at 23:07, Ard Biesheuvel wrote: >=20 > On Mon, 13 Feb 2023 at 22:32, Marvin H=C3=A4user = wrote: >>=20 >> Without wanting to blow up your RFC with another one - I discussed = this with various people, including Bret when he was still at Project = Mu, and there was a consensus among them that integrating the whole CPU = arch code right 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 never got the gist why you would want them = to be separate from DxeCore. Obviously there should be a level of = customizability for IBVs and OEMs, though that can be done = statically-linked as well. >>=20 >> REF: https://bugzilla.tianocore.org/show_bug.cgi?id=3D3223 >>=20 >> What's your take on this? >>=20 >=20 > 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. >=20 > 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.