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 7CE11941E18 for ; Thu, 1 Feb 2024 22:47:10 +0000 (UTC) DKIM-Signature: a=rsa-sha256; bh=GrTBVsYEsBNeGvj70DIpjPGbZY3DUjejGuchv1mD9hE=; c=relaxed/simple; d=groups.io; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From:In-Reply-To:Precedence:List-Subscribe:List-Help:Sender:List-Id:Mailing-List:Delivered-To:Reply-To:List-Unsubscribe-Post:List-Unsubscribe:Content-Language:Content-Type:Content-Transfer-Encoding; s=20140610; t=1706827629; v=1; b=dJGDaZ5X3yE4cJ8119QcgswCHIxOptoiT68qotgzccwP/v3D5Pz7gcyDSPt8KTiKMtSKZv0k E9w3r0+dakEg5x2aK+dXNo+DD4+fyHQHvReEpKxFd324DZXwS0OnO95ItbQgMc9QPVGSRggbeWd 0HYkdVkQOytMWuZkfdNjtns4= X-Received: by 127.0.0.2 with SMTP id idbiYY7687511xaUODnAmBNb; Thu, 01 Feb 2024 14:47:09 -0800 X-Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by mx.groups.io with SMTP id smtpd.web10.9772.1706827628251118348 for ; Thu, 01 Feb 2024 14:47:08 -0800 X-Received: from mimecast-mx02.redhat.com (mimecast-mx02.redhat.com [66.187.233.88]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-318-pOCqO7VPPH68VNrCHiYgtg-1; Thu, 01 Feb 2024 17:47:02 -0500 X-MC-Unique: pOCqO7VPPH68VNrCHiYgtg-1 X-Received: from smtp.corp.redhat.com (int-mx05.intmail.prod.int.rdu2.redhat.com [10.11.54.5]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 4C1CB84B04E; Thu, 1 Feb 2024 22:47:02 +0000 (UTC) X-Received: from [10.39.192.71] (unknown [10.39.192.71]) by smtp.corp.redhat.com (Postfix) with ESMTPS id B5E6A1BDB1; Thu, 1 Feb 2024 22:47:00 +0000 (UTC) Message-ID: <2a91f2f0-df4c-e106-65cd-79be167224f2@redhat.com> Date: Thu, 1 Feb 2024 23:46:55 +0100 MIME-Version: 1.0 Subject: Re: [edk2-devel] [PATCH v8 14/37] UefiCpuPkg: Add CpuMmuLib to UefiCpuPkg To: Chao Li , devel@edk2.groups.io Cc: Eric Dong , Ray Ni , Rahul Kumar , Gerd Hoffmann , Baoqi Zhang , Dongyan Qian , Xianglai Li , Bibo Mao References: <20240126062715.3099433-1-lichao@loongson.cn> <20240126062919.3101691-1-lichao@loongson.cn> <856ebd67-d345-6e41-2e34-74b9bdd7ed7e@redhat.com> From: "Laszlo Ersek" In-Reply-To: X-Scanned-By: MIMEDefang 3.4.1 on 10.11.54.5 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com 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,lersek@redhat.com List-Unsubscribe-Post: List-Unsubscribe=One-Click List-Unsubscribe: X-Gm-Message-State: 7Z1M0QKIjjW4OnFeXiz5ItGVx7686176AA= Content-Language: en-US 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=dJGDaZ5X; dmarc=fail reason="SPF not aligned (relaxed), DKIM not aligned (relaxed)" header.from=redhat.com (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 2/1/24 08:57, Chao Li wrote: > Let's me tell you this library how to work: >=20 > In PEI stage, in addition to ensuring that the MMU is not used, the user > must call the ConfigureMemoryManagementUnit toinitialization the MMU, > such as filling the static page tables, set the TLB refill exception > entry point, set the page size etc. the ConfigureMemoryManagementUnit is > a private API but related to ARCH. >=20 > During DXE stage, this library will provide services for CpuDxe and > other drivers, but almost changes to memory page attributes use the > protocols provided by CpuDxe. That is why the CpuMmuLib.h only contains > two APIs, it only can get/set the attribute. >=20 > In short, the PEI stage needs to initialize and set up TLB refill entry > point and method(dynamically populate the TLB, keep the PA =3D=3D VA), an= d > DXE stage is provides services for changing the memory attributes. My understanding is the following then: (1) You should provide a very low level library, implementing and also publicly exposing primitives for manipulating page tables. This library could / should expose ConfigureMemoryManagementUnit(). This library should not use global variables at all, I think -- the user of the library would be responsible for tracking state. API names in this library should have a good, distinctive prefix. (2) Introduce a higher level lib class that contains very few APIs -- APIs that are possible to implement by multiple arches. (3) Provide a library instance of class (2) by way of consuming (1). (4) In your platform PEIM, for setting up paging, use (1) directly, or (if you can do it) only (2)+(3). (5) In DXE phase code, use (2)+(3). Basically I both agree and disagree with Ray's review for your [PATCH v3 13/39] UefiCpuPkg: Add CpuMmuLib.h to UefiCpuPkg I think that Ray is right in that we want good high-level paging APIs that can be implemented by multiple arches. On the other hand, architectural differences do exist, they are idiosyncratic, they need to exist *somewhere*, and that idiosyncratic logic may still be necessary to use from *multiple* places -- so that indicates that we need a library (low-level) that is not "well designed" but actually a "grab bag of utilities" that just does the work. To satisfy both requirements, insert a new layer of indirection :) I'm not a big fan of top-down library design. I rather like to look at existent usage patterns, and then factoring out common stuff to a library. At that point, unification / cleanup possibilities may emerge. But getting the API design right immediately -- that requires seeing the future, or *extreme* amounts of experience. So an "ugly" interface library may be unavoidable. But, we can always wrap it into nicer interfaces, for those clients that don't really need the low-level primitives. Laszlo -=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 (#114972): https://edk2.groups.io/g/devel/message/114972 Mute This Topic: https://groups.io/mt/103971653/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-