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.web12.11913.1602244561285820244 for ; Fri, 09 Oct 2020 04:56:01 -0700 Authentication-Results: mx.groups.io; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=AxwPlFNn; 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=1602244560; 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=4SB2znKbCtlM/8y4vH4ssrnPGm2RWMuKLxRSNf2Q+AU=; b=AxwPlFNneokpR3sAvCQVliV02NE7sMy0CYtBfOfU4MZnYW4jgrbc9RK2zBwXiuMeMcX3kk rVZzVQCEMniekBaKbzP9zLeb9Gf118QW3KvqIGR4PmqeW3PyHp541oHAlzMTcSBJH6IIcu weFPUcZSJlGmZYaYmBbGHt4xm2P0eVo= 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-145-HMdZDO4lPmqqkmoBbYTNUg-1; Fri, 09 Oct 2020 07:55:58 -0400 X-MC-Unique: HMdZDO4lPmqqkmoBbYTNUg-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 17EAC57037; Fri, 9 Oct 2020 11:55:57 +0000 (UTC) Received: from lacos-laptop-7.usersys.redhat.com (ovpn-113-57.ams2.redhat.com [10.36.113.57]) by smtp.corp.redhat.com (Postfix) with ESMTP id EC4C06EF57; Fri, 9 Oct 2020 11:55:54 +0000 (UTC) Subject: Re: [edk2-devel] [RFC] Support Both MM Traditional and Standalone Drivers with One MM Core To: devel@edk2.groups.io, siyuan.fu@intel.com, "rfc@edk2.groups.io" Cc: "Dong, Eric" , "Ni, Ray" , "ard.biesheuvel@arm.com" , "sami.mujawar@arm.com" , "Yao, Jiewen" , "supreeth.venkatesh@arm.com" References: From: "Laszlo Ersek" Message-ID: <91565e60-54c5-8315-142b-d7b1309fca5a@redhat.com> Date: Fri, 9 Oct 2020 13:55:54 +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 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