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
***
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
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
On Thu, 2017-10-12 at 18:38 +0100, Achin Gupta wrote:
> Hi Supreeth,
>
> Could you acknowledge me as a contributor in the relevant patches and
> repost?
Can sure do as done in previous patches. However, Since I wanted you to
review as well the latest changes, I was not sure whether co-author can
be reviewer as well. I can add you as co-author in the next patchset,
if that is what you prefer.
>
> 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
On Thu, Oct 12, 2017 at 12:43:13PM -0500, Supreeth Venkatesh wrote:
> On Thu, 2017-10-12 at 18:38 +0100, Achin Gupta wrote:
> > Hi Supreeth,
> >
> > Could you acknowledge me as a contributor in the relevant patches and
> > repost?
> Can sure do as done in previous patches. However, Since I wanted you to
> review as well the latest changes, I was not sure whether co-author can
> be reviewer as well. I can add you as co-author in the next patchset,
> if that is what you prefer.
Yes I would prefer that!
Thanks!
Achin
>
> >
> > 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
© 2016 - 2024 Red Hat, Inc.