From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from alexa-out-sd-02.qualcomm.com (alexa-out-sd-02.qualcomm.com [199.106.114.39]) by mx.groups.io with SMTP id smtpd.web08.14712.1648145577801772624 for ; Thu, 24 Mar 2022 11:12:57 -0700 Authentication-Results: mx.groups.io; dkim=pass header.i=@quicinc.com header.s=qcdkim header.b=qLnksQcb; spf=pass (domain: quicinc.com, ip: 199.106.114.39, mailfrom: quic_llindhol@quicinc.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=quicinc.com; i=@quicinc.com; q=dns/txt; s=qcdkim; t=1648145577; x=1679681577; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=j2geAWB5/gu3VgN/kK2F0K5hAjl4GTAcVIbY0PYPOJk=; b=qLnksQcbHYQEqL8SDjNDc6CfGKVfmfzl/Mfote7E7B6jrRN0/iI/Isb/ DWzuNO0ilxABF8EiyegQZAH274/vKEX95pMNnfksooaGkgvmGe0xiTkkT J+MJguRCSuHF6YNrBaGF3nEWJpWnEqldx00Uo1vdEuaA2hgK3HQ01z2UF A=; Received: from unknown (HELO ironmsg-SD-alpha.qualcomm.com) ([10.53.140.30]) by alexa-out-sd-02.qualcomm.com with ESMTP; 24 Mar 2022 11:12:57 -0700 X-QCInternal: smtphost Received: from nasanex01c.na.qualcomm.com ([10.47.97.222]) by ironmsg-SD-alpha.qualcomm.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 24 Mar 2022 11:12:56 -0700 Received: from qc-i7.hemma.eciton.net (10.80.80.8) by nasanex01c.na.qualcomm.com (10.47.97.222) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.986.22; Thu, 24 Mar 2022 11:12:53 -0700 Date: Thu, 24 Mar 2022 18:12:50 +0000 From: "Leif Lindholm" To: Pierre Gondois CC: , , , , , , , , , , , , , Subject: Re: [edk2-devel] [PATCH v2 3/8] ArmPkg: Add Arm Firmware TRNG library Message-ID: References: <20211116113301.31088-1-sami.mujawar@arm.com> <20211116113301.31088-4-sami.mujawar@arm.com> <15621f6b-8df4-a65b-9996-92b68c1ae3c1@arm.com> <80941d66-5d31-053f-388a-95efe5dbbfdf@arm.com> <384ff0c1-374c-09c4-3bcb-8110dfda22e2@arm.com> MIME-Version: 1.0 In-Reply-To: <384ff0c1-374c-09c4-3bcb-8110dfda22e2@arm.com> Return-Path: quic_llindhol@quicinc.com X-Originating-IP: [10.80.80.8] X-ClientProxiedBy: nasanex01b.na.qualcomm.com (10.46.141.250) To nasanex01c.na.qualcomm.com (10.47.97.222) Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline On Thu, Mar 24, 2022 at 15:56:32 +0100, Pierre Gondois wrote: > > > > > +/** Invoke the monitor call using the appropriate conduit. > > > > > + If PcdMonitorConduitHvc is TRUE use the HVC conduit else use SMC conduit. > > > > > + > > > > > + @param [in, out] Args Arguments passed to and returned from the monitor. > > > > > + > > > > > + @return VOID > > > > > +**/ > > > > > +STATIC > > > > > +VOID > > > > > +ArmCallMonitor ( > > > > > + IN OUT ARM_MONITOR_ARGS *Args > > > > > + ) > > > > > +{ > > > > > + if (FeaturePcdGet (PcdMonitorConduitHvc)) { > > > > > + ArmCallHvc ((ARM_HVC_ARGS*)Args); > > > > > + } else { > > > > > + ArmCallSmc ((ARM_SMC_ARGS*)Args); > > > > > + } > > > > > +} > > > > Should this be in (a potentially renamed) ArmSmcLib? > > > [SAMI] Looking at ArmSmcLib and ArmHvcLib libraries there is not much > > > difference in the code other than the SMC/HVC call. Please let me know > > > if I should submit a patch to unify these in ArmMonitorLib? > > > The ArmCall APIs would still remain the same but moved to > > > ArmMonitorLib. > > > > Hello Leif, > > About your comment, I am not sure I understand it correctly. Assuming the > > function allowing to choose the conduit looks like: > > > > VOID > > EFIAPI > > ArmConduitCall (UINT8 Conduit) { > > if (Conduit == 0) { > > ArmCallHvc ((ARM_HVC_ARGS*)Args); > > } else if (Conduit == 1) { > > ArmCallSmc ((ARM_SMC_ARGS*)Args); > > } else { > > ASSERT (FALSE); > > } > > } > > > > Do you suggest to: > > 1. Make ArmSmcLib dependent on ArmHvcLib and add ArmConduitCall() > > in ArmSmcLib (or do the opposite with the ArmHvcLib) > > 2. Merge ArmSmcLib and ArmHvcLib in a new ArmConduitLibrary and add > > ArmConduitCall() in this new library. > > 3. Add an ArmConduitLibrary, relying on ArmSmcLib and ArmHvcLib, and having > > only one function: ArmConduitCall() > > > > > > 2. would make the Hvc and Smc calls really tied together. > > 3. would avoid creating new dependencies on existing libraries (i.e. a > > platform only using the ArmSmcLib would not require to have a NULL instance of > > ArmHvcLib). I assume you meant 3. I think 2 and 3 both capture the spirit of my request. 2 could potentially be achieved with a FixedPcd and conditionals in asm (less sure about the armasm/vs situation). I guess the question is if we think it plausible that a platform might both want to use this new ArmConduitCall *and* directly make use of ArmHvcLib/ArmSmcLib. Best Regards, Leif