From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-io0-x22b.google.com (mail-io0-x22b.google.com [IPv6:2607:f8b0:4001:c06::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ml01.01.org (Postfix) with ESMTPS id C47D721E1B761 for ; Fri, 22 Sep 2017 15:12:26 -0700 (PDT) Received: by mail-io0-x22b.google.com with SMTP id g32so5737479ioj.2 for ; Fri, 22 Sep 2017 15:15:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Yh5s9R1qUwv/Zq8eiiBkcASH7Gud/ceja/2SC4vuVRE=; b=HBtx17lAaoV4IfBD2eIw3xF7eieZb7Xh56U8yTzQKU6IXinb+uVqkbLn0u7shrKxEX P/+f1ApJIREiHFGNx21w01E2F7ctHpwe1/IhZJg0jaGyqH6Z0z3LwNGyjOeuAT1VBDMa taZpYXxrS2JRuPUDknyAtF2GkCKKRJtJQ7Iys= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Yh5s9R1qUwv/Zq8eiiBkcASH7Gud/ceja/2SC4vuVRE=; b=oigubhAu3PdLfwBD1WG0XtZhmc7GU+cimpaaHc3k8yNJOpw3JP2UbCTlNY0igAE1Q6 iiBKeBMv4p8Y3uxMPuEeYKPUauH0wS/JU2y7imj3UsPa2JLkYC2SPOFuoWoUJiIcVC85 Q6gGi1VWZWtCdzwgginsJo7q4TN/2+owCbC5gbtEnew/3apPBLWrDlpRs/qsGtXm0LfG 4Nz1om2jtfyB5752gAt4WfMNHB/vV6xr2MzQDyrRfGcPsIoF1GHeE3S3AMoPSc4//Uiv oHYKJGvQwtUHCQex5YROscb0/XVZ/boXH6iwqzesiDxEtUovnubdfiG61yO4yMaX5AVo SIAg== X-Gm-Message-State: AHPjjUg/Wui6HK6qCvcbJD6oJEzdbvMGwfrl24MjwQVnXWktIbI6K4nZ kOk7jptsSmrPhHXDzJxH6tJK0iWExZP5ZEfpOwHrkQ== X-Google-Smtp-Source: AOwi7QCMf4j+0jccSOIeg5G0c4cSXdkaRiG06zC5CezhoEurFvjKJaMbn/nbDqCt9MFjMKp0afaqauPZhRnKl2fiYRQ= X-Received: by 10.107.15.141 with SMTP id 13mr885463iop.141.1506118534444; Fri, 22 Sep 2017 15:15:34 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.152.18 with HTTP; Fri, 22 Sep 2017 15:15:33 -0700 (PDT) In-Reply-To: <1506118336.2623.5.camel@arm.com> References: <20170922192539.33085-1-supreeth.venkatesh@arm.com> <20170922214522.GM26498@e104320-lin> <1506118336.2623.5.camel@arm.com> From: Ard Biesheuvel Date: Fri, 22 Sep 2017 15:15:33 -0700 Message-ID: To: Supreeth Venkatesh Cc: Achin Gupta , "edk2-devel@lists.01.org" , Leif Lindholm , nd@arm.com Subject: Re: [PATCH 1/1] ArmPkg/Include: Add standard SMC and SVC function IDs for MM interface. X-BeenThere: edk2-devel@lists.01.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: EDK II Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Sep 2017 22:12:27 -0000 Content-Type: text/plain; charset="UTF-8" On 22 September 2017 at 15:12, Supreeth Venkatesh wrote: > On Fri, 2017-09-22 at 22:45 +0100, Achin Gupta wrote: >> Hi Supreeth, >> >> On Fri, Sep 22, 2017 at 08:25:39PM +0100, Supreeth Venkatesh wrote: >> > >> > This patch adds a list of function IDs that fall under the standard >> > SMC range as defined in >> > http://infocenter.arm.com/help/topic/com.arm.doc.den0060a/DEN0060A_ >> > ARM_MM_Interface_Specification.pdf. >> > >> > SMCs associated with Management Mode are in the range 0xC4000040 - >> > 0xC400005f (64 bit) and 0x84000040 - 0x8400005f (32 bit). >> > >> > The function(s) available to the normal world: >> > 1. Request services from the secure MM environment using >> > MM_COMMUNICATE. >> > >> > SVCs are in the range 0xC4000060 - 0xC400007f. >> > The functions available to the secure MM partition: >> > 1. Signal completion of MM event handling. >> > 2. Set/Get memory attributes for a memory region at runtime. >> > 3. Get version number of secure partition manager. >> > >> > Also, it defines memory attributes and MM return codes. >> The SVCs in the 0xC4000060 - 0xC400007f range are not a part of the >> MM interface >> specification. At the moment, these are used to implement an >> interface between >> ARM TF in EL3 and S-EL0. These should go into a separate patch that >> introduces >> them as an ARM TF ABI. >> >> cheers, >> Achin > > Thanks for taking a look at it. This was added in ArmStdSmc.h > deliberately to request comments/feedback. I don't think SVC defines > belong in this file at all. It should have its own header file. > > Since it is specific to MM (S-EL0) - EL3 communication, I am tempted to > create a new header file named "ArmMmSvc.h" and put in > ArmPkg/Include/IndustryStandard folder. > > Comments - Maintainers/Anyone? If these are only used for SVC calls from S-EL0, then yes, they should be in a separate header file.