From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [216.205.24.124]) by mx.groups.io with SMTP id smtpd.web10.13221.1602248869791870384 for ; Fri, 09 Oct 2020 06:07:50 -0700 Authentication-Results: mx.groups.io; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=T0STiZCV; spf=pass (domain: redhat.com, ip: 216.205.24.124, mailfrom: lersek@redhat.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1602248868; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=tsfxiwR2j5fGc8T369Zsw5d2b0QDIT/h1w9UzR9/vaA=; b=T0STiZCVf1Y57VdOJVCjmgHkXJXRI2trui2dtL24Z/A/hmEBtFWtG0574cT5oHtH4a885d XRc0NkfIaNLqwgLEyneU4Cx+mJbjKm4mDxR0K6JwOBgTD3RP3yT4hj+iTwGN+LC+oTqNdo zPV6REULt1GGVMMWcxAG36Rh3pcLk7s= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-291-WhGKW3g0PCqJQbjW8jy3oA-1; Fri, 09 Oct 2020 09:07:46 -0400 X-MC-Unique: WhGKW3g0PCqJQbjW8jy3oA-1 Received: from smtp.corp.redhat.com (int-mx03.intmail.prod.int.phx2.redhat.com [10.5.11.13]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 9F12F108E1A0; Fri, 9 Oct 2020 13:07:44 +0000 (UTC) Received: from lacos-laptop-7.usersys.redhat.com (ovpn-113-65.ams2.redhat.com [10.36.113.65]) by smtp.corp.redhat.com (Postfix) with ESMTP id 5087D6EF63; Fri, 9 Oct 2020 13:07:42 +0000 (UTC) Subject: Re: [edk2-rfc] [edk2-devel] [RFC] Support Both MM Traditional and Standalone Drivers with One MM Core To: "Yao, Jiewen" , "rfc@edk2.groups.io" , "devel@edk2.groups.io" , "Fu, Siyuan" Cc: "Dong, Eric" , "Ni, Ray" , "ard.biesheuvel@arm.com" , "sami.mujawar@arm.com" , "supreeth.venkatesh@arm.com" References: <91565e60-54c5-8315-142b-d7b1309fca5a@redhat.com> From: "Laszlo Ersek" Message-ID: <35c9e93e-5bd0-c932-c27c-183a687926c7@redhat.com> Date: Fri, 9 Oct 2020 15:07:41 +0200 MIME-Version: 1.0 In-Reply-To: X-Scanned-By: MIMEDefang 2.79 on 10.5.11.13 Authentication-Results: relay.mimecast.com; auth=pass smtp.auth=CUSA124A263 smtp.mailfrom=lersek@redhat.com X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit On 10/09/20 14:23, Yao, Jiewen wrote: > IMHO, StandaloneMm (in StandaloneMmPkg) should be the long term direction to replace the traditional MM (in MdeModulePkg). > > If we want to do some enhancement, I prefer #2 to update the one in StandaloneMmPkg. > Once we retire transitional MM, we can delete the PiSmmCore in MdeModulePkg. This is a good idea -- when we think we are ready to retire PiSmmCore in MdeModulePkg, because we think that StandaloneMmPkg can fully replace it, platforms can evaluate the latter (hopefully with some simple DSC / FDF modifications), and report back whether they see regressions or whether StandaloneMmPkg behaves as a drop-in replacement indeed, for PiSmmCore in MdeModulePkg. Thanks Laszlo > > If we choose #1, the EDKII will have two standaloneMm Cores (the one in StandaloneMmPkg and the one in MdeModulePkg), which may bring lots of confusing and we may need merge them later. > > Thank you > Yao Jiewen > >> -----Original Message----- >> From: rfc@edk2.groups.io On Behalf Of Laszlo Ersek >> Sent: Friday, October 9, 2020 7:56 PM >> To: devel@edk2.groups.io; Fu, Siyuan ; >> rfc@edk2.groups.io >> Cc: Dong, Eric ; Ni, Ray ; >> ard.biesheuvel@arm.com; sami.mujawar@arm.com; Yao, Jiewen >> ; supreeth.venkatesh@arm.com >> Subject: Re: [edk2-rfc] [edk2-devel] [RFC] Support Both MM Traditional and >> Standalone Drivers with One MM Core >> >> On 10/09/20 07:22, Siyuan, Fu wrote: >>> Hi, All >>> >>> This email is to collect feedback about making one common EDK2 MM Core >> driver to support both MM Traditional drivers and MM Standalone drivers. >>> >>> We know that PI Spec defines two types of MM-related drivers: MM >> Traditional Drivers and MM Standalone Drivers. There are two MM Core >> modules exist in EDK2 but each of them can only support one single type of MM >> drivers: >>> - PiSmmCore in MdeModulePkg supports MM Traditional driver dispatch. It >> doesn't have FV parsing logic and relies on EFI Firmware Volume2 Protocol for >> driver discovery. It doesn't support MM Standalone driver. >>> - StandaloneMmCore in StandaloneMmPkg supports MM Standalone driver >> dispatch. It has FV parsing and decompress logic but only limited to one single >> firmware volume (called standalone BFV in code). It doesn't support MM >> Traditional driver. >>> >>> However, a platform may want to have both of the two types of MM drivers >> coexist in its firmware, for example, when it tries to transfer from Traditional >> MM mode to Standalone MM mode, in a stage by stage manner. However, it's >> not possible with current EDK2 MM Core because of above limitations. Thus, >> here we propose to have a common MM Core module in EDK2, which could: >>> - Support both MM Traditional drivers and MM Standalone drivers. >>> - Use shared Depex evaluation when dispatching all the MM drivers. >>> - Use a shared MM System Table when invoking all the MM drivers' entry >> point, which mean handle/protocol database is shared. >>> - Have self-contained FV parsing and driver discovery capability. >>> >>> We realized there could be 2 possible options to make this happen: >>> - Option 1: Update the MdeModulePkg Core. In this approach, we will need >> to add the FV decompress, driver discovery and MM Standalone driver >> dispatcher to the PiSmmCore module in MdeModulePkg. >>> - Option 2: Update the StandaloneMmPkg Core. Which means adding MM >> Traditional dispatcher and multiple FV support to existing standalone Core in >> StandaloneMmPkg. Will also need to add PEI/DXE IPL module to invoke the >> Standalone MM Core and pass UEFI System Table to it. >>> >>> The option 1 will have less impact to those platforms which only use MM >> Standalone drivers currently, because those platforms can stay with the >> unchanged Standalone MM Core. While option 2 looks more like a clean >> solution because it could support all the cases (Traditional MM only, Standalone >> MM only, and mix-used platform). So I'd like to hear the community's feedback >> about which option is preferred, and let me know if you have any concerns with >> this change. Thanks! >> >> Which method is the least risky with regard to regressions, in your opinion? >> >> I tend to prefer #2. Either option is neutral for ArmVirtPkg at the >> moment, and option#2 is safer for OvmfPkg (no risk of regression). Thus >> far, there has not been any need (that I know of) for OVMF to support >> standalone MM drivers. >> >> Furthermore, if we wanted to add Management Mode support to ArmVirtPkg >> at some (later) point, I believe (?) we'd just use StandaloneMmPkg right >> from the start. >> >> I.e., from my perspective, mixing MM module types, for some kind of >> transition for a platform from one MM mode to another, is not >> immediately useful; so my goal is to minimize the risk of regressions. >> >> Thanks >> Laszlo >> >> >> >> >> >