Message ID | 20230410182058.8949-1-quic_nkela@quicinc.com |
---|---|
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a59:b0ea:0:b0:3b6:4342:cba0 with SMTP id b10csp2077091vqo; Mon, 10 Apr 2023 11:31:09 -0700 (PDT) X-Google-Smtp-Source: AKy350Z9mDOH46FfnlLa3w4CPaKm9wE+m0fd9cn0doTBChwb8j0gEbSr5WsblfQk0X5BHnwcfub8 X-Received: by 2002:a17:906:1d4c:b0:879:d438:4d1c with SMTP id o12-20020a1709061d4c00b00879d4384d1cmr8367236ejh.21.1681151468903; Mon, 10 Apr 2023 11:31:08 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1681151468; cv=none; d=google.com; s=arc-20160816; b=sX1psjcRch4O/cCX9bobN7Rwm83FbyyEDGUaYTPyaCt5cNngDbheS/iv2z/+SFxl8o Xpux+U0ZSjD5jNPUbeiDrL5m4b/d56n7JzGb3ggi7GNr9hc9Id04ue+U3o6Gu4/lyBCa COwnRcijCzrTa8k/5X43KDPhkFNQl/z34aG6pAzhVG6EpWu2L7oopiBjTRig2TVqoed8 mHF3+OhXV5Tik2mLvppezhXPjzR2z8pCJn1kD64sAF7yo2Vw/dmrES1T6CHabb/+WOAy kpxa8x2gc4px/N1yhyTFPWS/9Mdg5dArlHCg3BO4iXy00iAtmFgKueZqarS/aTtfJVnI y80g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:mime-version:references:in-reply-to:message-id :date:subject:cc:to:from:dkim-signature; bh=am50PlryRRfYXJ4hjNZEKIeFgwMZ+ijTi/TRPQme2VA=; b=eZqq3aY//nBlMynluhZYIBJPCbCqSQxTKv58MXKJ6SJHJzCPAiz0fXtPqN3MA5Uf+V XTEMV1zVBMy2yCFPo2rUqjuj8ekk9ObjSPlTqBa7AmY9UkmwWu4YlBwk7eWr39ZfklJz CFGb4sha3oMU+QeRBYLp5KoHL7Ks8WdB9WJaXXqTOiDMXXqKhmO7spo2BhbMvRBE2oEK 0mzOavTezh0ziNWLvynTbmCMzDZVdGJgHzX/ywCh4llEKq2FCNbM8tcrAECqGmm92vbw kiA+XV5gRPcPFhXw+/L5Y/mEPz5NxdEQ0jR4k3qxs2J3/p1VxUzqXr7Y8gyGZN/efmQm FUug== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@quicinc.com header.s=qcppdkim1 header.b=FC0JUOHa; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=quicinc.com Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id qa44-20020a17090786ac00b0093bd1b12b6esi9209884ejc.385.2023.04.10.11.30.44; Mon, 10 Apr 2023 11:31:08 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@quicinc.com header.s=qcppdkim1 header.b=FC0JUOHa; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=quicinc.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229688AbjDJSVj (ORCPT <rfc822;yuanzuo1009@gmail.com> + 99 others); Mon, 10 Apr 2023 14:21:39 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:35868 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229671AbjDJSVh (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Mon, 10 Apr 2023 14:21:37 -0400 Received: from mx0a-0031df01.pphosted.com (mx0a-0031df01.pphosted.com [205.220.168.131]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 9877F1FD5; Mon, 10 Apr 2023 11:21:36 -0700 (PDT) Received: from pps.filterd (m0279863.ppops.net [127.0.0.1]) by mx0a-0031df01.pphosted.com (8.17.1.19/8.17.1.19) with ESMTP id 33AFxBE8010960; Mon, 10 Apr 2023 18:21:21 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=quicinc.com; h=from : to : cc : subject : date : message-id : in-reply-to : references : mime-version : content-type; s=qcppdkim1; bh=am50PlryRRfYXJ4hjNZEKIeFgwMZ+ijTi/TRPQme2VA=; b=FC0JUOHaNzmz9vWK8giQ2W7+P9QDZ8g/SMHx4aMSAqdmeww9NNGYC6RFAS7XrXub5bwf BgqRBN8DjrIkZ1bPqTjfXIDlnldneiPUJqKiy75CTrue+kprz21+J0hIQB6r6RLwZir4 VmtSZh7Hx0nlHoI8GMLGflOTLfwdDi5g6JIHvFBLmYcW5YmzmnqusDKVYuTIIzZIDh2W RpXco1SbjXY7/yzGF21wNPyu2JPUKlYzpt3IIXDSqfqV6GJ/YdJYfWw6F47CgmSSYhvd FxqNOs1WdXzDeoaPzpjC79fFrqaPPttPhy3uZ2uTooah9Wl0t0wvp/vMmTnAfZy2pRYO +Q== Received: from nalasppmta01.qualcomm.com (Global_NAT1.qualcomm.com [129.46.96.20]) by mx0a-0031df01.pphosted.com (PPS) with ESMTPS id 3pvgkgh1mj-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 10 Apr 2023 18:21:21 +0000 Received: from nalasex01c.na.qualcomm.com (nalasex01c.na.qualcomm.com [10.47.97.35]) by NALASPPMTA01.qualcomm.com (8.17.1.5/8.17.1.5) with ESMTPS id 33AILJvp017053 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 10 Apr 2023 18:21:19 GMT Received: from car-linux11.qualcomm.com (10.80.80.8) by nalasex01c.na.qualcomm.com (10.47.97.35) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.986.42; Mon, 10 Apr 2023 11:21:19 -0700 From: Nikunj Kela <quic_nkela@quicinc.com> To: <sudeep.holla@arm.com> CC: <cristian.marussi@arm.com>, <robh+dt@kernel.org>, <krzysztof.kozlowski+dt@linaro.org>, <linux-arm-kernel@lists.infradead.org>, <devicetree@vger.kernel.org>, <linux-kernel@vger.kernel.org>, <lkp@intel.com>, Nikunj Kela <quic_nkela@quicinc.com> Subject: [PATCH v2 0/2] Allow parameter in smc/hvc calls Date: Mon, 10 Apr 2023 11:20:56 -0700 Message-ID: <20230410182058.8949-1-quic_nkela@quicinc.com> X-Mailer: git-send-email 2.17.1 In-Reply-To: <20230409181918.29270-1-quic_nkela@quicinc.com> References: <20230409181918.29270-1-quic_nkela@quicinc.com> MIME-Version: 1.0 Content-Type: text/plain X-Originating-IP: [10.80.80.8] X-ClientProxiedBy: nasanex01b.na.qualcomm.com (10.46.141.250) To nalasex01c.na.qualcomm.com (10.47.97.35) X-QCInternal: smtphost X-Proofpoint-Virus-Version: vendor=nai engine=6200 definitions=5800 signatures=585085 X-Proofpoint-GUID: 3T-b2-G6oYniM6opK5TLZbO8q-KhfSVV X-Proofpoint-ORIG-GUID: 3T-b2-G6oYniM6opK5TLZbO8q-KhfSVV X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.254,Aquarius:18.0.942,Hydra:6.0.573,FMLib:17.11.170.22 definitions=2023-04-10_13,2023-04-06_03,2023-02-09_01 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 clxscore=1011 impostorscore=0 mlxscore=0 suspectscore=0 spamscore=0 priorityscore=1501 malwarescore=0 adultscore=0 bulkscore=0 mlxlogscore=449 phishscore=0 lowpriorityscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2303200000 definitions=main-2304100158 X-Spam-Status: No, score=-0.9 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_LOW,SPF_HELO_NONE,SPF_PASS autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1762724360781620836?= X-GMAIL-MSGID: =?utf-8?q?1762815082725795087?= |
Series |
Allow parameter in smc/hvc calls
|
|
Message
Nikunj Kela
April 10, 2023, 6:20 p.m. UTC
Currently, smc/hvc calls are made with parameters set to zeros. We are using multiple scmi instances within a VM and hypervisor associates a tag with each instance and expects the tag in hvc calls from that instance, while sharing the same smc-id(func_id) among the instances. This patch series introduces new optional dtb bindings which can be used to pass parameters to smc/hvc calls. --- v2 -> fix the compilation erros on 32bit platform(see below) Reported-by: kernel test robot <lkp@intel.com> Closes: https://lore.kernel.org/oe-kbuild-all/202304100606.kUjhsRYf-lkp@intel.com/ v1 -> original patches Nikunj Kela (2): dt-bindings: firmware: arm,scmi: support parameter passing in smc/hvc firmware: arm_scmi: Augment SMC/HVC to allow optional parameters .../bindings/firmware/arm,scmi.yaml | 17 +++++ drivers/firmware/arm_scmi/smc.c | 72 ++++++++++++++++++- 2 files changed, 88 insertions(+), 1 deletion(-)
Comments
On Mon, Apr 10, 2023 at 11:20:56AM -0700, Nikunj Kela wrote: > Currently, smc/hvc calls are made with parameters set > to zeros. We are using multiple scmi instances within > a VM and hypervisor associates a tag with each instance > and expects the tag in hvc calls from that instance, while > sharing the same smc-id(func_id) among the instances. > > This patch series introduces new optional dtb bindings which > can be used to pass parameters to smc/hvc calls. > Just to be sure that I understood the problem(as your 2 parameters confused me), this is just to help hypervisor/secure side to identify the right channel/shared memory when the same SMC/HVC function id is shared right ? If that is the case, why can't we just pass the shmem address as the parameter ? I would like to avoid fragmentation here with every vendor trying to do different things to achieve the same. I would just change the driver to do that. Not sure if it breaks any existing implementation or not. If it does, we can add another compatible to identify one needing this fixed(shmem address) as additional parameter. Does that make sense at all ? Or am I missing some/all of the requirements here ?
On 4/11/2023 6:01 AM, Sudeep Holla wrote: > On Mon, Apr 10, 2023 at 11:20:56AM -0700, Nikunj Kela wrote: >> Currently, smc/hvc calls are made with parameters set >> to zeros. We are using multiple scmi instances within >> a VM and hypervisor associates a tag with each instance >> and expects the tag in hvc calls from that instance, while >> sharing the same smc-id(func_id) among the instances. >> >> This patch series introduces new optional dtb bindings which >> can be used to pass parameters to smc/hvc calls. >> > Just to be sure that I understood the problem(as your 2 parameters confused > me), this is just to help hypervisor/secure side to identify the right > channel/shared memory when the same SMC/HVC function id is shared right ? that's somewhat correct. Our hypervisor allocates 64bit ids on every boot for each scmi instance which it uses to identify the scmi instance. Additionally, our hypervisor also categorizes events within each instance by an event-id that gets passed to hvc call as second parameter. So we can pass two parameters in addition to function_id. > > If that is the case, why can't we just pass the shmem address as the > parameter ? I would like to avoid fragmentation here with every vendor > trying to do different things to achieve the same. that's a good suggestion. Any solution you propose shouldn't just limit to only one parameter. IMO, there should be some way to pass all 6 parameters since we do have a use case of at least two parameters. > > I would just change the driver to do that. Not sure if it breaks any existing > implementation or not. If it does, we can add another compatible to identify > one needing this fixed(shmem address) as additional parameter. > > Does that make sense at all ? Or am I missing some/all of the requirements > here ? The shmem proposal is fine however please also incorporate passing of other parameters. >
On Tue, Apr 11, 2023 at 07:42:50AM -0700, Nikunj Kela wrote: > that's a good suggestion. Any solution you propose shouldn't just limit to > only one parameter. IMO, there should be some way to pass all 6 parameters > since we do have a use case of at least two parameters. Please elaborate on your use-case. > The shmem proposal is fine however please also incorporate passing of other > parameters. You are missing the point here. SMC/HVC is just a doorbell and the main point I made earlier is that there is no need for vendors to try colourful things here if it is not necessary. So no, I don't want any extra bindings or more than one param is that is not needed. I will wait for the reason as requested above.
On 4/12/2023 1:37 AM, Sudeep Holla wrote: > On Tue, Apr 11, 2023 at 07:42:50AM -0700, Nikunj Kela wrote: > >> that's a good suggestion. Any solution you propose shouldn't just limit to >> only one parameter. IMO, there should be some way to pass all 6 parameters >> since we do have a use case of at least two parameters. > Please elaborate on your use-case. Based on your comments below, we will change our hypervisor to make use of shmem. > >> The shmem proposal is fine however please also incorporate passing of other >> parameters. > You are missing the point here. SMC/HVC is just a doorbell and the main point > I made earlier is that there is no need for vendors to try colourful things > here if it is not necessary. So no, I don't want any extra bindings or more > than one param is that is not needed. I will wait for the reason as requested > above. ok, understood. In that case, we will change our hypervisor to use shmem address as instance identifier. Please add support for one param, thanks!