rfc@edk2.groups.io | [edk2-devel] [RFC] Support Both MM Traditional and Standalone Drivers with One MM Core

Home Messages Hashtags

Date Date 1 - 8 of 8

[edk2-devel] [RFC] Support Both MM Traditional and Standalone Drivers with One MM Core

Laszlo Ersek #431 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
More All Messages By This Member
Laszlo Ersek #432 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 <rfc@edk2.groups.io> On Behalf Of Laszlo Ersek Sent: Friday, October 9, 2020 7:56 PM To: devel@edk2.groups.io; Fu, Siyuan <siyuan.fu@...>; rfc@edk2.groups.io Cc: Dong, Eric <eric.dong@...>; Ni, Ray <ray.ni@...>; ard.biesheuvel@...; sami.mujawar@...; Yao, Jiewen <jiewen.yao@...>; supreeth.venkatesh@... 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
More All Messages By This Member
Yao, Jiewen #433 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. 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 toggle quoted message Show quoted text -----Original Message----- From: rfc@edk2.groups.io <rfc@edk2.groups.io> On Behalf Of Laszlo Ersek Sent: Friday, October 9, 2020 7:56 PM To: devel@edk2.groups.io; Fu, Siyuan <siyuan.fu@...>; rfc@edk2.groups.io Cc: Dong, Eric <eric.dong@...>; Ni, Ray <ray.ni@...>; ard.biesheuvel@...; sami.mujawar@...; Yao, Jiewen <jiewen.yao@...>; supreeth.venkatesh@... 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
More All Messages By This Member
Siyuan, Fu <siyuan.fu@...> #434 Hi, Jiewen/Laszlo Thanks for your comments on this. Hi, Ard/Sami/Supreeth Since ARM based platforms are currently the major user of the MM Core in StandaloneMmPkg, I would like to hear you idea about this change. Do you have any concern about adding MM Traditional driver support to the Standalone MM Core? Best Regards Siyuan toggle quoted message Show quoted text -----Original Message----- From: devel@edk2.groups.io <devel@edk2.groups.io> On Behalf Of Laszlo Ersek Sent: 2020年10月9日 21:08 To: Yao, Jiewen <jiewen.yao@...>; rfc@edk2.groups.io; devel@edk2.groups.io; Fu, Siyuan <siyuan.fu@...> Cc: Dong, Eric <eric.dong@...>; Ni, Ray <ray.ni@...>; ard.biesheuvel@...; sami.mujawar@...; supreeth.venkatesh@... Subject: Re: [edk2-rfc] [edk2-devel] [RFC] Support Both MM Traditional and Standalone Drivers with One MM Core 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 <rfc@edk2.groups.io> On Behalf Of Laszlo Ersek Sent: Friday, October 9, 2020 7:56 PM To: devel@edk2.groups.io; Fu, Siyuan <siyuan.fu@...>; rfc@edk2.groups.io Cc: Dong, Eric <eric.dong@...>; Ni, Ray <ray.ni@...>; ard.biesheuvel@...; sami.mujawar@...; Yao, Jiewen <jiewen.yao@...>; supreeth.venkatesh@... 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
More All Messages By This Member
Sami Mujawar #435 Hi Siyuan, I can see the following points: - current code organisation is such that the traditional MM and standalone MM are clearly separated. - traditional MM is planned to be deprecated. - some architectures only support standalone MM (e.g. Arm platforms) - life span of MM Migration use-case code is until traditional MM is deprecated. Considering the above, would it be possible to have an option 3 where the MM Migration use-case code is placed in a separate location/package, such that existing platforms do not need changing and are not regressed? I understand the concern with duplicating the MM implementations, however I think it would be good to maintain the demarcation that exists between traditional MM and standalone MM. Features that are beneficial to standalone MM can certainly be added to StandaloneMmPkg. Regards, Sami Mujawar toggle quoted message Show quoted text -----Original Message----- From: Fu, Siyuan <siyuan.fu@...> Sent: 10 October 2020 02:41 AM To: devel@edk2.groups.io; lersek@...; Yao, Jiewen <jiewen.yao@...>; rfc@edk2.groups.io; Laszlo Ersek (lersek@...) <lersek@...> Cc: Dong, Eric <eric.dong@...>; Ni, Ray <ray.ni@...>; Ard Biesheuvel <Ard.Biesheuvel@...>; Sami Mujawar <Sami.Mujawar@...>; Supreeth Venkatesh <Supreeth.Venkatesh@...> Subject: RE: [edk2-rfc] [edk2-devel] [RFC] Support Both MM Traditional and Standalone Drivers with One MM Core Hi, Jiewen/Laszlo Thanks for your comments on this. Hi, Ard/Sami/Supreeth Since ARM based platforms are currently the major user of the MM Core in StandaloneMmPkg, I would like to hear you idea about this change. Do you have any concern about adding MM Traditional driver support to the Standalone MM Core? Best Regards Siyuan -----Original Message----- From: devel@edk2.groups.io <devel@edk2.groups.io> On Behalf Of Laszlo Ersek Sent: 2020年10月9日 21:08 To: Yao, Jiewen <jiewen.yao@...>; rfc@edk2.groups.io; devel@edk2.groups.io; Fu, Siyuan <siyuan.fu@...> Cc: Dong, Eric <eric.dong@...>; Ni, Ray <ray.ni@...>; ard.biesheuvel@...; sami.mujawar@...; supreeth.venkatesh@... Subject: Re: [edk2-rfc] [edk2-devel] [RFC] Support Both MM Traditional and Standalone Drivers with One MM Core 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 <rfc@edk2.groups.io> On Behalf Of Laszlo Ersek Sent: Friday, October 9, 2020 7:56 PM To: devel@edk2.groups.io; Fu, Siyuan <siyuan.fu@...>; rfc@edk2.groups.io Cc: Dong, Eric <eric.dong@...>; Ni, Ray <ray.ni@...>; ard.biesheuvel@...; sami.mujawar@...; Yao, Jiewen <jiewen.yao@...>; supreeth.venkatesh@... 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 IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
More All Messages By This Member
Siyuan, Fu <siyuan.fu@...> #436 Hi, Sami I know the traditional MM is planned to be deprecated but the reality is that there are many existing traditional MM platforms/drivers and the migration has to happen step-by-step. It may take a long time like several years, not days or months. Not sure if we really want to maintain duplicate code in 3 different MM cores in EDK2 for such a long time. Would you think it's acceptable if we put the traditional MM related code controlled by a feature flag PCD in StandaloneMmPkg core? The default value of the PCD can be set as disabled so those existing platforms doesn't need to be changed. Best Regards Siyuan toggle quoted message Show quoted text -----Original Message----- From: devel@edk2.groups.io <devel@edk2.groups.io> On Behalf Of Sami Mujawar Sent: 2020年10月15日 18:12 To: Fu, Siyuan <siyuan.fu@...>; devel@edk2.groups.io; lersek@...; Yao, Jiewen <jiewen.yao@...>; rfc@edk2.groups.io; Laszlo Ersek (lersek@...) <lersek@...> Cc: Dong, Eric <eric.dong@...>; Ni, Ray <ray.ni@...>; Ard Biesheuvel <Ard.Biesheuvel@...>; Supreeth Venkatesh <Supreeth.Venkatesh@...> Subject: Re: [edk2-rfc] [edk2-devel] [RFC] Support Both MM Traditional and Standalone Drivers with One MM Core Hi Siyuan, I can see the following points: - current code organisation is such that the traditional MM and standalone MM are clearly separated. - traditional MM is planned to be deprecated. - some architectures only support standalone MM (e.g. Arm platforms) - life span of MM Migration use-case code is until traional MM is deprecated. Considering the above, would it be possible to have an option 3 where the MM Migration use-case code is placed in a separate location/package, such that existing platforms do not need changing and are not regressed? I understand the concern with duplicating the MM implementations, however I think it would be good to maintain the demarcation that exists between traditional MM and standalone MM. Features that are beneficial to standalone MM can certainly be added to StandaloneMmPkg. Regards, Sami Mujawar -----Original Message----- From: Fu, Siyuan <siyuan.fu@...> Sent: 10 October 2020 02:41 AM To: devel@edk2.groups.io; lersek@...; Yao, Jiewen <jiewen.yao@...>; rfc@edk2.groups.io; Laszlo Ersek (lersek@...) <lersek@...> Cc: Dong, Eric <eric.dong@...>; Ni, Ray <ray.ni@...>; Ard Biesheuvel <Ard.Biesheuvel@...>; Sami Mujawar <Sami.Mujawar@...>; Supreeth Venkatesh <Supreeth.Venkatesh@...> Subject: RE: [edk2-rfc] [edk2-devel] [RFC] Support Both MM Traditional and Standalone Drivers with One MM Core Hi, Jiewen/Laszlo Thanks for your comments on this. Hi, Ard/Sami/Supreeth Since ARM based platforms are currently the major user of the MM Core in StandaloneMmPkg, I would like to hear you idea about this change. Do you have any concern about adding MM Traditional driver support to the Standalone MM Core? Best Regards Siyuan -----Original Message----- From: devel@edk2.groups.io <devel@edk2.groups.io> On Behalf Of Laszlo Ersek Sent: 2020年10月9日 21:08 To: Yao, Jiewen <jiewen.yao@...>; rfc@edk2.groups.io; devel@edk2.groups.io; Fu, Siyuan <siyuan.fu@...> Cc: Dong, Eric <eric.dong@...>; Ni, Ray <ray.ni@...>; ard.biesheuvel@...; sami.mujawar@...; supreeth.venkatesh@... Subject: Re: [edk2-rfc] [edk2-devel] [RFC] Support Both MM Traditional and Standalone Drivers with One MM Core 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 <rfc@edk2.groups.io> On Behalf Of Laszlo Ersek Sent: Friday, October 9, 2020 7:56 PM To: devel@edk2.groups.io; Fu, Siyuan <siyuan.fu@...>; rfc@edk2.groups.io Cc: Dong, Eric <eric.dong@...>; Ni, Ray <ray.ni@...>; ard.biesheuvel@...; sami.mujawar@...; Yao, Jiewen <jiewen.yao@...>; supreeth.venkatesh@... 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 IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
More All Messages By This Member
Ard Biesheuvel <ard.biesheuvel@...> #437 On 10/16/20 3:36 AM, Fu, Siyuan wrote: Hi, Sami I know the traditional MM is planned to be deprecated but the reality is that there are many existing traditional MM platforms/drivers and the migration has to happen step-by-step. It may take a long time like several years, not days or months. Not sure if we really want to maintain duplicate code in 3 different MM cores in EDK2 for such a long time. Could you explain more about the gap that needs to be bridged here? I suppose the desire is to be able to reuse existing DXE_SMM_DRIVER modules, and deploy them unmodified in a standalone MM context? So would you expect runtime dispatch for these drivers? What about any accesses to EFI boot services, which are no longer possible when running under standalone MM? Do you have any reason to believe that this hybrid MM core will be able to run a significant fraction of those existing drivers? Would you think it's acceptable if we put the traditional MM related code controlled by a feature flag PCD in StandaloneMmPkg core? The default value of the PCD can be set as disabled so those existing platforms doesn't need to be changed. This is security critical code, and having PCD controlled behavior like this makes it much hard to reason about correctness in all its instantiation. I guess I would have to see what the code looks like, but having PCD checks all over the place does not seem like a great way to do this IMHO. -- Ard.
More All Messages By This Member
Siyuan, Fu <siyuan.fu@...> #438 toggle quoted message Show quoted text -----Original Message----- From: devel@edk2.groups.io <devel@edk2.groups.io> On Behalf Of Ard Biesheuvel Sent: 2020年10月16日 15:04 To: Fu, Siyuan <siyuan.fu@...>; devel@edk2.groups.io; sami.mujawar@...; lersek@...; Yao, Jiewen <jiewen.yao@...>; rfc@edk2.groups.io Cc: Dong, Eric <eric.dong@...>; Ni, Ray <ray.ni@...>; Supreeth Venkatesh <Supreeth.Venkatesh@...> Subject: Re: [edk2-rfc] [edk2-devel] [RFC] Support Both MM Traditional and Standalone Drivers with One MM Core On 10/16/20 3:36 AM, Fu, Siyuan wrote: Hi, Sami I know the traditional MM is planned to be deprecated but the reality is that there are many existing traditional MM platforms/drivers and the migration has to happen step-by-step. It may take a long time like several years, not days or months. Not sure if we really want to maintain duplicate code in 3 different MM cores in EDK2 for such a long time. Could you explain more about the gap that needs to be bridged here? I suppose the desire is to be able to reuse existing DXE_SMM_DRIVER modules, and deploy them unmodified in a standalone MM context? Yes you are correct. Without a hybrid MM core, the MM drivers must be either all traditional MM or all standalone MM. While a platform may have tens or even hundreds of traditional MM drivers for now, it's hard to covert all of them into standalone as a single step. It looks ideal from architecture perspective but actually very hard for a read product execution. So it will be good if there is a hybrid MM core which can support both the unmodified traditional MM driver, and converted standalone MM driver. So would you expect runtime dispatch for these drivers? What about any accesses to EFI boot services, which are no longer possible when running under standalone MM? Do you have any reason to believe that this hybrid MM core will be able to run a significant fraction of those existing drivers? Runtime dispatch for standalone MM driver can be supported, but runtime dispatch for traditional MM driver is not required (actually prohibited). The hybrid MM core can distinguish the type of an MM module and decide if it can be dispatched at a given execution point. Would you think it's acceptable if we put the traditional MM related code controlled by a feature flag PCD in StandaloneMmPkg core? The default value of the PCD can be set as disabled so those existing platforms doesn't need to be changed. This is security critical code, and having PCD controlled behavior like this makes it much hard to reason about correctness in all its instantiation. I guess I would have to see what the code looks like, but having PCD checks all over the place does not seem like a great way to do this IMHO. I understand your concern. So I assume we all understand the value for having a hybrid MM core, but the question is whether adding to existing StandaloneMmPkg Core or a 3rd MM core in EDK2, right? I think we can leave this as an open and make decision when reviewing the patch. Thanks. Siyuan -- Ard.
More All Messages By This Member

1 - 8 of 8

1

Previous Topic Next Topic

Home Hashtags About Features Pricing Updates Terms Help Twitter