Hi Supreeth,
Could you acknowledge me as a contributor in the relevant patches and repost?
cheers,
Achin
On Thu, Oct 12, 2017 at 06:13:49PM +0100, Supreeth Venkatesh wrote:
> ***
> PI v1.5 Specification Volume 4 defines Management Mode Core Interface
> and defines EFI_MM_COMMUNICATION_PROTOCOL. This protocol provides a
> means of communicating between drivers outside of MM and MMI
> handlers inside of MM.
>
> EFI_MM_COMMUNICATION_PROTOCOL
> Summary
> This protocol provides a means of communicating between drivers outside of
> MM and MMI
> handlers inside of MM.
>
> GUID
> #define EFI_MM_COMMUNICATION_PROTOCOL_GUID \
> { 0xc68ed8e2, 0x9dc6, 0x4cbd, 0x9d, 0x94, 0xdb, 0x65, 0xac, 0xc5, 0xc3,
> 0x32 }
>
> Prototype
> typedef struct _EFI_MM_COMMUNICATION_PROTOCOL {
> EFI_MM_COMMUNICATE Communicate;
> } EFI_MM_COMMUNICATION_PROTOCOL;
>
> Members
> Communicate
> Sends/receives a message for a registered handler. See the Communicate()
> function description.
>
> Description
> This protocol provides runtime services for communicating between DXE
> drivers and a registered
> MMI handler.
>
> EFI_MM_COMMUNICATION_PROTOCOL.Communicate()
> Summary
> Communicates with a registered handler.
>
> Prototype
> typedef
> EFI_STATUS
> (EFIAPI *EFI_MM_COMMUNICATE) (
> IN CONST EFI_MM_COMMUNICATION_PROTOCOL *This,
> IN OUT VOID *CommBuffer,
> IN OUT UINTN *CommSize OPTIONAL
> );
>
> Parameters
> This - The EFI_MM_COMMUNICATION_PROTOCOL instance.
> CommBuffer - Pointer to the buffer to convey into MMRAM.
> CommSize - The size of the data buffer being passed in. On exit, the size
> of data being returned.
> Zero if the handler does not wish to reply with any
> data. This parameter is optional
> and may be NULL.
>
> Description
> This function provides a service to send and receive messages from a
> registered UEFI service. The EFI_MM_COMMUNICATION_PROTOCOL driver is
> responsible for doing any of the
> copies such that the data lives in boot-service-accessible RAM.
> A given implementation of the EFI_MM_COMMUNICATION_PROTOCOL may choose to
> use the EFI_MM_CONTROL_PROTOCOL for effecting the mode transition, or it may
> use some other method.
> The agent invoking the communication interface at runtime may be virtually
> mapped. The MM infrastructure code and handlers, on the other hand, execute
> in physical mode. As a result, the non-MM agent,
> which may be executing in the virtual-mode OS context (as a result of an OS
> invocation of the UEFI SetVirtualAddressMap() service), should use a
> contiguous memory buffer with a physical address before
> invoking this service. If the virtual address of the buffer is used, the MM
> Driver may not know how to do the appropriate virtual-to-physical conversion.
> To avoid confusion in interpreting frames, the CommunicateBuffer parameter
> should always begin with EFI_MM_COMMUNICATE_HEADER, which is defined in
> Related Definitions below.
> The header data is mandatory for messages sent into the MM agent.
> If the CommSize parameter is omitted the MessageLength field in the
> EFI_MM_COMMUNICATE_HEADER,
> in conjunction with the size of the header itself, can be used to ascertain
> the total size of the communication payload.
> If the MessageLength is zero, or too large for the MM implementation to
> manage, the MM implementation must update the MessageLength to reflect the
> size of the Data buffer that it can tolerate.
> If the CommSize parameter is passed into the call, but the integer it
> points to, has a value of 0, then this must be updated to reflect the maximum
> size of the CommBuffer that the implementation can tolerate.
> Once inside of MM, the MM infrastructure will call all registered handlers
> with the same HandlerType as the GUID specified by HeaderGuid and the
> CommBuffer pointing to Data.
> This function is not reentrant.
> The standard header is used at the beginning of the
> EFI_MM_INITIALIATION_HEADER structure during MM initialization. See "Related
> Definitions" below for more information.
>
> Related Definitions
> typedef struct {
> EFI_GUID HeaderGuid;
> UINTN MessageLength;
> UINT8 Data[ANYSIZE_ARRAY];
> } EFI_MM_COMMUNICATE_HEADER;
>
> HeaderGuid - Allows for disambiguation of the message format. Type EFI_GUID
> is defined in
> InstallProtocolInterface() in the UEFI Specification.
> MessageLength - Describes the size of Data (in bytes) and does not include
> the size of the header.
> Data - Designates an array of bytes that is MessageLength in size.
>
> Status Codes Returned
> EFI_SUCCESS - The message was successfully posted.
> EFI_INVALID_PARAMETER - The buffer was NULL.
> EFI_BAD_BUFFER_SIZE - The buffer is too large for the MM implementation. If
> this error is
> returned, the MessageLength field
> in the CommBuffer
> header or the integer pointed by
> CommSize, are updated to reflect
> the maximum payload size the
> implementation can accommodate.
> See the function description above
> for more details.
> EFI_ACCESS_DENIED - The CommunicateBuffer parameter or CommSize
> parameter, if not omitted, are in
> address range that cannot be
> accessed by the MM environment.
>
> This patchset implements it on AARCH64 Platform.
> ***
>
> Supreeth Venkatesh (3):
> ArmPkg/Drivers: Add EFI_MM_COMMUNICATION_PROTOCOL DXE driver.
> ArmPkg/Drivers: Add ArmMmCommunication Driver information file.
> ArmPkg: Add PCDs needed for MM communication driver.
>
> ArmPkg/ArmPkg.dec | 3 +
> .../Drivers/MmCommunicationDxe/MmCommunication.c | 314
> +++++++++++++++++++++
> .../Drivers/MmCommunicationDxe/MmCommunication.inf | 50 ++++
> 3 files changed, 367 insertions(+)
> create mode 100644 ArmPkg/Drivers/MmCommunicationDxe/MmCommunication.c
> create mode 100644 ArmPkg/Drivers/MmCommunicationDxe/MmCommunication.inf
>
> --
> 2.14.1
>
_______________________________________________
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
