public inbox for devel@edk2.groups.io
 help / color / mirror / Atom feed
From: Supreeth Venkatesh <supreeth.venkatesh@arm.com>
To: Achin Gupta <achin.gupta@arm.com>
Cc: edk2-devel@lists.01.org, leif.lindholm@linaro.org,
	 ard.biesheuvel@linaro.org, nd@arm.com
Subject: Re: [PATCH v1 0/3] *** EFI_MM_COMMUNICATION_PROTOCOL ***
Date: Thu, 12 Oct 2017 12:43:13 -0500	[thread overview]
Message-ID: <1507830193.3189.6.camel@arm.com> (raw)
In-Reply-To: <20171012173829.GT26498@e104320-lin>

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
> > 


  reply	other threads:[~2017-10-12 17:39 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-10-12 17:13 [PATCH v1 0/3] *** EFI_MM_COMMUNICATION_PROTOCOL *** Supreeth Venkatesh
2017-10-12 17:13 ` [PATCH v1 1/3] ArmPkg/Drivers: Add EFI_MM_COMMUNICATION_PROTOCOL DXE driver Supreeth Venkatesh
2017-10-12 17:29   ` Ard Biesheuvel
2017-10-25 16:40     ` Supreeth Venkatesh
2017-10-12 17:13 ` [PATCH v1 2/3] ArmPkg/Drivers: Add ArmMmCommunication Driver information file Supreeth Venkatesh
2017-10-12 17:13 ` [PATCH v1 3/3] ArmPkg: Add PCDs needed for MM communication driver Supreeth Venkatesh
2017-10-12 17:18   ` Ard Biesheuvel
2017-10-12 17:27     ` Supreeth Venkatesh
2017-10-12 17:38 ` [PATCH v1 0/3] *** EFI_MM_COMMUNICATION_PROTOCOL *** Achin Gupta
2017-10-12 17:43   ` Supreeth Venkatesh [this message]
2017-10-12 17:51     ` Achin Gupta

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-list from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1507830193.3189.6.camel@arm.com \
    --to=devel@edk2.groups.io \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox