On 02/20/19 13:23, Ard Biesheuvel wrote: > On Wed, 20 Feb 2019 at 06:53, Jagadeesh Ujja <jagadeesh.u...@arm.com> wrote: >> >> hi Ard, >> On Tue, Feb 19, 2019 at 6:55 PM Ard Biesheuvel >> <ard.biesheu...@linaro.org> wrote: >>> >>> Hello Jagadeesh, >>> >>> On Tue, 19 Feb 2019 at 11:47, Jagadeesh Ujja <jagadeesh.u...@arm.com> wrote: >>>> >>>> In preparation for providing a standalone MM based non-secure variable >>>> runtime driver, factor out some portions that are specific to the >>>> traditional driver, mainly related to locating variable arch protocol >>>> and variable write arch protocol, which are not required to be located >>>> when using standalone MM based secure variable implementation. >>>> >>> >>> While i think this change is correct from a technical perspective, I >>> don't think this is the right approach. >>> >> these changes are mandatory, this is one of the possible solution. >> >>> It was a deliberate decision to expose the MM services in a way that >>> only the producer of the communication protocol is aware of the >>> implementation details, i.e., whether it is backed by tradtional MM or >>> standalone MM. >>> >> can you please provide more details on how "exposing the MM services" >> will help to resolve the issue here. if this helps, definitely i will use >> that. >> > > Let me rephrase this for the benefit of the MdeModulePkg maintainers, > and ask them their opinion. > > Currently, the DXE runtime driver that produces the architectural > varstore protocols that are based on communication with MM components > living elsewhere, rely on the EFI protocol database for sequencing. > I.e., after dispatch, they wait for certain protocols to be installed > into the DXE protocol database by the SMM drivers before proceeding to > install the variable arch protocols. > > This does not work for standalone MM, since it has no access to the > DXE protocol database, nor is it needed, since it may be assumed that > the MM execution context is fully configured by the time the DXE phase > starts. > > Jagadeesh's proposal is to factor this out, and create two different > .INFs to build the same DXE runtime driver in two different ways. This > defeats the purpose of having an abstract MM communication protocol, > so it is something I would like to avoid. On the other hand, is it not > obvious how to parameterize this requirement in another way. > > For the moment, I could live with putting this into a library, and > leave it up to the platform to ensure the combination of the library > resolution with the driver that produces the MM communicate protocol > is a sane one. > > Any thoughts?
I think I'm missing the gist of the library approach; still, would it be possible for affected platforms (i.e. those that depend on standalone MM) to procude the necessary DXE protocols (for unblocking the variable runtime driver) in a platform DXE driver? Thanks Laszlo _______________________________________________ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
