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 674FF9417C0 for ; Mon, 13 Nov 2023 11:02:18 +0000 (UTC) DKIM-Signature: a=rsa-sha256; bh=NVwMP7HQrrguDTTwJ2+nNHyot59Tw62Ue3tWeZ1oklE=; 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=1699873337; v=1; b=XPa5w+zpGTT4gHOSuvoPlHlSv0krHt+TGrArwXJ2P++k2yJRzZWab+UZeKgfvnr38dz74nR5 jRkaWLVKPuZ07wRmJYl65zBZwDxQc0oBNLgV4uDaTGvWOwOpYfRAUBySFtNEq0bSXU8WQ5XNFvj UJVlhjoJU6ZAWmQYvLfZwUMw= X-Received: by 127.0.0.2 with SMTP id g4xHYY7687511xwklBK95Is0; Mon, 13 Nov 2023 03:02:17 -0800 X-Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by mx.groups.io with SMTP id smtpd.web11.34461.1699873336319750387 for ; Mon, 13 Nov 2023 03:02:16 -0800 X-Received: from mimecast-mx02.redhat.com (mx-ext.redhat.com [66.187.233.73]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-63-0-eRndRVMriAlwow_rWqvQ-1; Mon, 13 Nov 2023 06:02:12 -0500 X-MC-Unique: 0-eRndRVMriAlwow_rWqvQ-1 X-Received: from smtp.corp.redhat.com (int-mx07.intmail.prod.int.rdu2.redhat.com [10.11.54.7]) (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 0D028299E74A; Mon, 13 Nov 2023 11:02:12 +0000 (UTC) X-Received: from [10.39.192.220] (unknown [10.39.192.220]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 89D041C060B9; Mon, 13 Nov 2023 11:02:10 +0000 (UTC) Message-ID: <0568d2a8-54e7-730e-24c2-0c619b886b50@redhat.com> Date: Mon, 13 Nov 2023 12:02:09 +0100 MIME-Version: 1.0 Subject: Re: [edk2-devel] [PATCH v2 23/30] OvmfPkg/LoongArchVirt: Add PeiServiceTablePointerLib To: Chao Li , devel@edk2.groups.io Cc: Ard Biesheuvel , Jiewen Yao , Jordan Justen , Gerd Hoffmann , Xianglai Li , Bibo Mao References: <20231106032521.2251143-1-lichao@loongson.cn> <20231106033012.2294174-1-lichao@loongson.cn> <1736e6c6-f455-48f3-9b68-04f2fd2c70ec@loongson.cn> From: "Laszlo Ersek" In-Reply-To: <1736e6c6-f455-48f3-9b68-04f2fd2c70ec@loongson.cn> X-Scanned-By: MIMEDefang 3.4.1 on 10.11.54.7 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: w9Xb7ljpASsKjxz0FeXW3NPrx7686176AA= 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=XPa5w+zp; 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 11/10/23 07:44, Chao Li wrote: > Hi Laszlo, >=20 > This is a good question, same as the previous email, some ARCH don't > require running code on memory during PEI phase or other reason can not > used the MdePkg version, so this pointer will be saved by some register, > I saw the ArmPkg version also uses a register to save this pointer. >=20 > If I move ArmPkg version PeiServiceTablePointer to MdePkg and the method > of getting and saving the pointer use a new library which related > architecture, other word, the API of PeiServiceTablePointer has not > changed, adding a new library that PeiServiceTablePointer depends on, > the real saving and reading method completed in the new library. Do you > think this way is better? Right. I think you need a loongarch-specific library instance of PeiServicesTablePointerLib under MdePkg. Presumably, if / when you enable edk2 on *physical* loongarch platforms, you're going to need the same library instance. And therefore it should not be under OvmfPkg, but MdePkg. In fact, now that I'm reading the comments in "MdePkg/Library/PeiServicesTablePointerLibIdt/PeiServicesTablePointer.c", it seems that the architecture bindings in the Platform Init specification actually document how the PEI services table pointer is supposed to be stored before system memory becomes available (IIUC). The latest version of the PI spec that I have is 1.8. In Volume I, there is a section titled "I-9.4 PEI Services Table Retrieval". It considers the following architectures: X86, x64, Itanium, ARM, AArch64, RISC-V. I think that in the longer term, you should file a PIWG Mantis ticket for extending this section, with an Engineering Change Request where you describe how this mechanism should work on loongarch. And then the implementation certainly belongs to MdePkg. (Note that I'm *not* saying you should first update the specification and then implement it in edk2 -- that's not my point. My point is that *eventually*, this mechanism will become a part of the public loongarch bindings, and therefore you can already start introducing it under MdePkg, in my opinion anyway.) Note that "prior art" is inconsistent here, regarding edk2 locations, because, as you say, the arm/aarch64 implementation lives under ArmPkg -- but it's quite unlikely IMO that a LoongArchPkg top-level directory would be introduced. In the longer term, we might want to consolidate all PeiServicesTablePointerLib instances under MdePkg. Then your question is, IIUC, whether to reuse any portion of the ArmPkg implementation. I don't think that's necessary; the library is so small, there is effectively *nothing generic* in it. Put differently, all of it is architecture specific. Thus I think you can just add a totally self-contained loongarch instance. 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 (#111139): https://edk2.groups.io/g/devel/message/111139 Mute This Topic: https://groups.io/mt/102413901/7686176 Group Owner: devel+owner@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/leave/12367111/7686176/19134562= 12/xyzzy [rebecca@openfw.io] -=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-