Received: by 2002:a05:7412:3b8b:b0:fc:a2b0:25d7 with SMTP id nd11csp1098235rdb; Fri, 9 Feb 2024 10:07:25 -0800 (PST) X-Forwarded-Encrypted: i=3; AJvYcCUhSn8HTuktxxgr0Hy5JXgzAEegGZzes9YH2MymVzyfcdRdU1keHohzhQ2hSzEt+QKz8dDZFnYMdNRK5+I9QD/BNBn2/4WLuVfK1jw58g== X-Google-Smtp-Source: AGHT+IGYIlvSx8lG2x/mObsYggoN4fj71+Dlp+z/oXZ9IBenLxZRR/V21OF6sBbNWFh4/6cHqg82 X-Received: by 2002:a17:906:af06:b0:a36:2df:5ded with SMTP id lx6-20020a170906af0600b00a3602df5dedmr2085024ejb.72.1707502044968; Fri, 09 Feb 2024 10:07:24 -0800 (PST) ARC-Seal: i=2; a=rsa-sha256; t=1707502044; cv=pass; d=google.com; s=arc-20160816; b=SW350xDy2w8ociNDhDht4fum5JDgAY35r9ojbRoLYyK2K3oy6bh1tefU/4wNrsIKZJ 8ZJ45EvIUj12LNkpzFClUY0WHf5Rk1kG/OiMdpPkZx8iT1woWD0eN1coOLEddQPetRx0 17TnjhFoA2UGoIss3oSGLPPEgXUO7natYGBYRqBMDqm1DM24u5VMRbNXM4v2po8S6qdY shnAmd7PsoD/feREeolgdv5GnAknCIDTe1JgseaSHN+0cpu6paELkdWrqX7v44oAvHNb KZHR9TDMDY+hOg9gyX230qUl6gDc/9mAnbhkoAPMkzJxF+lIONc5FPSBx6nyldAIX+Jq Bc3g== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:list-unsubscribe:list-subscribe:list-id:precedence :references:mail-followup-to:message-id:subject:cc:to:from:date :dkim-signature; bh=vnF6cW9AwSEXpnrdJ2qBgomPvqggGqG2cuf4kWBk5Uc=; fh=g1dSgtzyf/qhwm/AjE4TTM/PvSlrraHHQJcSvlf+ySA=; b=dBY9fMnguDSU1+ivs4sJQBdNhxXomv/JmXrtvPgsOYeOf8R/sK7pFIetj6vJjjT89U uuMx/HZY360C7PDt/uHxzLbb82/GZeim6VI9niXPul7r2mMHcVNr3Bd58VRtksyAK+YN 3z0HHz4ICFCtduWYjn9ayhHUOlbDI7C/c9fkiiwM0LXl+lkHaPwe92hUxgAwmDSaRjzW DUPNKmhq9IZUWVqZ/MSMiN3t9zdBCxVcEkpps/yQvO7qrQ0mLp1YJv7KxbBCW/hIoskQ ztVPHVB/zufOttmiolZkRHoK3w6gi6e9wE9V1qqiVWyN/oEpY/nHqpOZEt39b7ZtZcAj D8Ow==; dara=google.com ARC-Authentication-Results: i=2; mx.google.com; dkim=pass header.i=@quicinc.com header.s=qcppdkim1 header.b=RoMQDEB4; arc=pass (i=1 spf=pass spfdomain=quicinc.com dkim=pass dkdomain=quicinc.com dmarc=pass fromdomain=quicinc.com); spf=pass (google.com: domain of linux-kernel+bounces-59762-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.80.249 as permitted sender) smtp.mailfrom="linux-kernel+bounces-59762-linux.lists.archive=gmail.com@vger.kernel.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=quicinc.com X-Forwarded-Encrypted: i=2; AJvYcCX7AR31dFlzjibrSz8Y4DhXbqtK4MIlpreXk1u4bsnJxHDlQqv+GygPK7A8601WpxDd6qif7VXsB5cMGXeerKiEsEqHTvcOMiKwJRGcMQ== Return-Path: Received: from am.mirrors.kernel.org (am.mirrors.kernel.org. [147.75.80.249]) by mx.google.com with ESMTPS id f16-20020a170906049000b00a3bf7ac0ff7si691899eja.97.2024.02.09.10.07.24 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 09 Feb 2024 10:07:24 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel+bounces-59762-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.80.249 as permitted sender) client-ip=147.75.80.249; Authentication-Results: mx.google.com; dkim=pass header.i=@quicinc.com header.s=qcppdkim1 header.b=RoMQDEB4; arc=pass (i=1 spf=pass spfdomain=quicinc.com dkim=pass dkdomain=quicinc.com dmarc=pass fromdomain=quicinc.com); spf=pass (google.com: domain of linux-kernel+bounces-59762-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.80.249 as permitted sender) smtp.mailfrom="linux-kernel+bounces-59762-linux.lists.archive=gmail.com@vger.kernel.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=quicinc.com Received: from smtp.subspace.kernel.org (wormhole.subspace.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by am.mirrors.kernel.org (Postfix) with ESMTPS id 78B6A1F2368C for ; Fri, 9 Feb 2024 18:07:24 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 481977F493; Fri, 9 Feb 2024 18:07:17 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=quicinc.com header.i=@quicinc.com header.b="RoMQDEB4" Received: from mx0b-0031df01.pphosted.com (mx0b-0031df01.pphosted.com [205.220.180.131]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 072B67BB1C; Fri, 9 Feb 2024 18:07:13 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=205.220.180.131 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1707502035; cv=none; b=s8l6oo/r1ed7Pj2VkEAj9Wm631Merhp2MqrfK0uEcD6SM4LoF7YVL0CXz0eF6B72uhhgsZ7bAw1PCMIfj4595qmlopq5+EpY4C7PCMA+HoPJ+VGWdUVRbn+lFghpbuMuhXzjrzOZ/3pSZmiQC4q00zJHeF0h75HCTuFi6xyfvSc= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1707502035; c=relaxed/simple; bh=Ngv1x6ieRVx+BX8M/kVpUPLzSNbknuTzCXdefJob5Ag=; h=Date:From:To:CC:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=Im0lvC6b3qEhKQxpSQDxmJlS91Y0CHW5xNR7cCQUinhDOhe3ljLT7vNuteZGz+z/pTHJk0nEIswkQEe8XEm3NjOjOZacddbQxlY2wBA3/tZpRKd0LFK7yHMzN23OScHd/Ng4LU6mMkOnJgrXpILGhxovD/KsMENblCiSWyEMwtw= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=quicinc.com; spf=pass smtp.mailfrom=quicinc.com; dkim=pass (2048-bit key) header.d=quicinc.com header.i=@quicinc.com header.b=RoMQDEB4; arc=none smtp.client-ip=205.220.180.131 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=quicinc.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=quicinc.com Received: from pps.filterd (m0279871.ppops.net [127.0.0.1]) by mx0a-0031df01.pphosted.com (8.17.1.24/8.17.1.24) with ESMTP id 419Hh7Fb004803; Fri, 9 Feb 2024 18:07:09 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=quicinc.com; h= date:from:to:cc:subject:message-id:references:mime-version :content-type:content-transfer-encoding:in-reply-to; s= qcppdkim1; bh=vnF6cW9AwSEXpnrdJ2qBgomPvqggGqG2cuf4kWBk5Uc=; b=Ro MQDEB47m2seA8mQkVIgg+SPE2vzrOaVcjMFhtZWlv7HLrO2Wmn2WNin0kM6FTOsU EWHXBoWXXbIn7zOkLVKNF0uBfla2kTDnUzA/rdCHggc1kTCeL3PyEu2qYNPbrC9e A3l8M7g159i7M91h6iGLlblAzurIjq97xrQv9NtLX12mfr2Gri4qcaj5QsyXHLeK W1ghXlLSv9V5kzNnQrFEokHmleRCQ5Xl4RA8JGXZJYp7duWVyE0lbXAe92H5SOP9 P7P4L9SQf/ZmKSYlTErG97++FjgpzRoLxx6S5ziCJ9bGqH2p+cvbVRHWvRfq+upy ihXvVt+RgUXMHBuI22IQ== Received: from nasanppmta05.qualcomm.com (i-global254.qualcomm.com [199.106.103.254]) by mx0a-0031df01.pphosted.com (PPS) with ESMTPS id 3w5gk2h67p-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 09 Feb 2024 18:07:08 +0000 (GMT) Received: from nasanex01b.na.qualcomm.com (nasanex01b.na.qualcomm.com [10.46.141.250]) by NASANPPMTA05.qualcomm.com (8.17.1.5/8.17.1.5) with ESMTPS id 419I770i008104 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 9 Feb 2024 18:07:07 GMT Received: from hu-eberman-lv.qualcomm.com (10.49.16.6) by nasanex01b.na.qualcomm.com (10.46.141.250) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.1118.40; Fri, 9 Feb 2024 10:06:59 -0800 Date: Fri, 9 Feb 2024 10:06:59 -0800 From: Elliot Berman To: Dibakar Singh CC: , , , , , , , , , , Subject: Re: [PATCH] firmware: qcom_scm: Introduce batching of hyp assign calls Message-ID: <7fhl7uvhl26whumcl3f5hxflczws67lg3yq4gb5fyrig2ziux6@chft6orl6xne> Mail-Followup-To: Dibakar Singh , andersson@kernel.org, konrad.dybcio@linaro.org, krzysztof.kozlowski@linaro.org, luzmaximilian@gmail.com, bartosz.golaszewski@linaro.org, quic_gurus@quicinc.com, linux-arm-msm@vger.kernel.org, linux-kernel@vger.kernel.org, quic_guptap@quicinc.com, quic_pkondeti@quicinc.com, quic_pheragu@quicinc.com References: <20240209112536.2262967-1-quic_dibasing@quicinc.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20240209112536.2262967-1-quic_dibasing@quicinc.com> X-ClientProxiedBy: nalasex01a.na.qualcomm.com (10.47.209.196) To nasanex01b.na.qualcomm.com (10.46.141.250) X-QCInternal: smtphost X-Proofpoint-Virus-Version: vendor=nai engine=6200 definitions=5800 signatures=585085 X-Proofpoint-ORIG-GUID: 7mq0R81Q7yvKRh_wT5wB9Gn-SiC55-0n X-Proofpoint-GUID: 7mq0R81Q7yvKRh_wT5wB9Gn-SiC55-0n X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.272,Aquarius:18.0.1011,Hydra:6.0.619,FMLib:17.11.176.26 definitions=2024-02-09_15,2024-02-08_01,2023-05-22_02 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 mlxscore=0 lowpriorityscore=0 phishscore=0 malwarescore=0 mlxlogscore=999 spamscore=0 impostorscore=0 suspectscore=0 clxscore=1011 bulkscore=0 priorityscore=1501 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.19.0-2401310000 definitions=main-2402090130 On Fri, Feb 09, 2024 at 04:55:36PM +0530, Dibakar Singh wrote: > Expose an API qcom_scm_assign_table to allow client drivers to batch > multiple memory regions in a single hyp assign call. > > In the existing situation, if our goal is to process an sg_table and > transfer its ownership from the current VM to a different VM, we have a > couple of strategies. The first strategy involves processing the entire > sg_table at once and then transferring the ownership. However, this > method may have an adverse impact on the system because during an SMC > call, the NS interrupts are disabled, and this delay could be > significant when dealing with large sg_tables. To address this issue, we > can adopt a second strategy, which involves processing each sg_list in > the sg_table individually and reassigning memory ownership. Although > this method is slower and potentially impacts performance, it will not > keep the NS interrupts disabled for an extended period. > > A more efficient strategy is to process the sg_table in batches. This > approach addresses both scenarios by involving memory processing in > batches, thus avoiding prolonged NS interrupt disablement for longer > duration when dealing with large sg_tables. Moreover, since we process > in batches, this method is faster compared to processing each item > individually. The observations on testing both the approaches for > performance is as follows: > > Allocation Size/ 256MB 512MB 1024MB > Algorithm Used =========== =========== ============ > > Processing each sg_list 73708(us) 149289(us) 266964(us) > in sg_table one by one > > Processing sg_table in 46925(us) 92691(us) 176893(us) > batches > > This implementation serves as a wrapper around the helper function > __qcom_scm_assign_mem, which takes an sg_list and processes it in > batches. We’ve set the limit to a minimum of 32 sg_list in a batch or a > total batch size of 512 pages. The selection of these numbers is > heuristic, based on the test runs conducted. Opting for a smaller number > would compromise performance, while a larger number would result in > non-secure interrupts being disabled for an extended duration. > > Co-developed-by: Prakruthi Deepak Heragu > Signed-off-by: Prakruthi Deepak Heragu > Signed-off-by: Dibakar Singh > --- > drivers/firmware/qcom/qcom_scm.c | 211 +++++++++++++++++++++++++ > include/linux/firmware/qcom/qcom_scm.h | 7 + > 2 files changed, 218 insertions(+) > > diff --git a/drivers/firmware/qcom/qcom_scm.c b/drivers/firmware/qcom/qcom_scm.c > index 520de9b5633a..038b96503d65 100644 > --- a/drivers/firmware/qcom/qcom_scm.c > +++ b/drivers/firmware/qcom/qcom_scm.c > @@ -21,6 +21,8 @@ > #include > #include > #include > +#include > +#include > > #include "qcom_scm.h" > > @@ -1048,6 +1050,215 @@ int qcom_scm_assign_mem(phys_addr_t mem_addr, size_t mem_sz, > } > EXPORT_SYMBOL_GPL(qcom_scm_assign_mem); > > +/** > + * qcom_scm_assign_mem_batch() - Make a secure call to reassign memory > + * ownership of several memory regions > + * @mem_regions: A buffer describing the set of memory regions that need to > + * be reassigned > + * @nr_mem_regions: The number of memory regions that need to be reassigned > + * @srcvms: A buffer populated with he vmid(s) for the current set of > + * owners > + * @src_sz: The size of the srcvms buffer (in bytes) > + * @destvms: A buffer populated with the new owners and corresponding > + * permission flags. > + * @dest_sz: The size of the destvms buffer (in bytes) > + * > + * Return negative errno on failure, 0 on success. > + */ > +static int qcom_scm_assign_mem_batch(struct qcom_scm_mem_map_info *mem_regions, > + size_t nr_mem_regions, u32 *srcvms, > + size_t src_sz, > + struct qcom_scm_current_perm_info *destvms, > + size_t dest_sz) > +{ > + dma_addr_t mem_dma_addr; > + size_t mem_regions_sz; > + int ret = 0, i; > + > + for (i = 0; i < nr_mem_regions; i++) { > + mem_regions[i].mem_addr = cpu_to_le64(mem_regions[i].mem_addr); > + mem_regions[i].mem_size = cpu_to_le64(mem_regions[i].mem_size); > + } > + > + mem_regions_sz = nr_mem_regions * sizeof(*mem_regions); > + mem_dma_addr = dma_map_single(__scm->dev, mem_regions, mem_regions_sz, > + DMA_TO_DEVICE); > + if (dma_mapping_error(__scm->dev, mem_dma_addr)) { > + dev_err(__scm->dev, "mem_dma_addr mapping failed\n"); > + return -ENOMEM; > + } > + > + ret = __qcom_scm_assign_mem(__scm->dev, virt_to_phys(mem_regions), > + mem_regions_sz, virt_to_phys(srcvms), src_sz, > + virt_to_phys(destvms), dest_sz); > + > + dma_unmap_single(__scm->dev, mem_dma_addr, mem_regions_sz, DMA_TO_DEVICE); > + return ret; > +} > + > +/** > + * qcom_scm_prepare_mem_batch() - Prepare batches of memory regions > + * @sg_table: A scatter list whose memory needs to be reassigned > + * @srcvms: A buffer populated with he vmid(s) for the current set of > + * owners > + * @nr_src: The number of the src_vms buffer > + * @destvms: A buffer populated with he vmid(s) for the new owners > + * @destvms_perms: A buffer populated with the permission flags of new owners > + * @nr_dest: The number of the destvms > + * @last_sgl: Denotes to the last scatter list element. Used in case of rollback > + * @roll_back: Identifies whether we are executing rollback in case of failure > + * > + * Return negative errno on failure, 0 on success. > + */ > +static int qcom_scm_prepare_mem_batch(struct sg_table *table, > + u32 *srcvms, int nr_src, > + int *destvms, int *destvms_perms, > + int nr_dest, > + struct scatterlist *last_sgl, bool roll_back) > +{ > + struct qcom_scm_current_perm_info *destvms_cp; > + struct qcom_scm_mem_map_info *mem_regions_buf; > + struct scatterlist *curr_sgl = table->sgl; > + dma_addr_t source_dma_addr, dest_dma_addr; > + size_t batch_iterator; > + size_t batch_start = 0; > + size_t destvms_cp_sz; > + size_t srcvms_cp_sz; > + size_t batch_size; > + u32 *srcvms_cp; > + int ret = 0; > + int i; > + > + if (!table || !table->sgl || !srcvms || !nr_src || > + !destvms || !destvms_perms || !nr_dest || !table->nents) > + return -EINVAL; > + > + srcvms_cp_sz = sizeof(*srcvms_cp) * nr_src; > + srcvms_cp = kmemdup(srcvms, srcvms_cp_sz, GFP_KERNEL); > + if (!srcvms_cp) > + return -ENOMEM; > + > + for (i = 0; i < nr_src; i++) > + srcvms_cp[i] = cpu_to_le32(srcvms_cp[i]); > + > + source_dma_addr = dma_map_single(__scm->dev, srcvms_cp, > + srcvms_cp_sz, DMA_TO_DEVICE); Please use the new tzmem allocator: https://lore.kernel.org/all/20240205182810.58382-1-brgl@bgdev.pl/ > + > + if (dma_mapping_error(__scm->dev, source_dma_addr)) { > + ret = -ENOMEM; > + goto out_free_source; > + } > + > + destvms_cp_sz = sizeof(*destvms_cp) * nr_dest; > + destvms_cp = kzalloc(destvms_cp_sz, GFP_KERNEL); > + > + if (!destvms_cp) { > + ret = -ENOMEM; > + goto out_unmap_source; > + } > + > + for (i = 0; i < nr_dest; i++) { > + destvms_cp[i].vmid = cpu_to_le32(destvms[i]); > + destvms_cp[i].perm = cpu_to_le32(destvms_perms[i]); > + destvms_cp[i].ctx = 0; > + destvms_cp[i].ctx_size = 0; > + } > + > + dest_dma_addr = dma_map_single(__scm->dev, destvms_cp, > + destvms_cp_sz, DMA_TO_DEVICE); > + if (dma_mapping_error(__scm->dev, dest_dma_addr)) { > + ret = -ENOMEM; > + goto out_free_dest; > + } > + > + mem_regions_buf = kcalloc(QCOM_SCM_MAX_BATCH_SECTION, sizeof(*mem_regions_buf), > + GFP_KERNEL); > + if (!mem_regions_buf) > + return -ENOMEM; > + > + while (batch_start < table->nents) { > + batch_size = 0; > + batch_iterator = 0; > + > + do { > + mem_regions_buf[batch_iterator].mem_addr = page_to_phys(sg_page(curr_sgl)); > + mem_regions_buf[batch_iterator].mem_size = curr_sgl->length; > + batch_size += curr_sgl->length; > + batch_iterator++; > + if (roll_back && curr_sgl == last_sgl) > + break; > + curr_sgl = sg_next(curr_sgl); > + } while (curr_sgl && batch_iterator < QCOM_SCM_MAX_BATCH_SECTION && > + curr_sgl->length + batch_size < QCOM_SCM_MAX_BATCH_SIZE); > + > + batch_start += batch_iterator; > + > + ret = qcom_scm_assign_mem_batch(mem_regions_buf, batch_iterator, > + srcvms_cp, srcvms_cp_sz, destvms_cp, destvms_cp_sz); > + > + if (ret) { > + dev_info(__scm->dev, "Failed to assign memory protection, ret = %d\n", ret); > + last_sgl = curr_sgl; > + ret = -EADDRNOTAVAIL; Probably should not be changing the ret value. What happens to the memory that has been assigned so far? How do we reclaim that? > + break; > + } > + if (roll_back && curr_sgl == last_sgl) > + break; > + } > + kfree(mem_regions_buf); > + > + dma_unmap_single(__scm->dev, dest_dma_addr, > + destvms_cp_sz, DMA_TO_DEVICE); > + > +out_free_dest: > + kfree(destvms_cp); > +out_unmap_source: > + dma_unmap_single(__scm->dev, source_dma_addr, > + srcvms_cp_sz, DMA_TO_DEVICE); > +out_free_source: > + kfree(srcvms_cp); > + return ret; > +} > + > +/** > + * qcom_scm_assign_table() - Make a call to prepare batches of memory regions > + * and reassign memory ownership of several memory regions at once > + * @sg_table: A scatter list whose memory needs to be reassigned > + * @srcvms: A buffer populated with he vmid(s) for the current set of > + * owners > + * @nr_src: The number of the src_vms buffer > + * @destvms: A buffer populated with he vmid(s) for the new owners > + * @destvms_perms: A buffer populated with the permission flags of new owners > + * @nr_dest: The number of the destvms > + * > + * Return negative errno on failure, 0 on success. > + */ > +int qcom_scm_assign_table(struct sg_table *table, > + u32 *srcvms, int nr_src, > + int *destvms, int *destvms_perms, > + int nr_dest) > +{ > + struct scatterlist *last_sgl = NULL; > + int rb_ret = 0; > + u32 new_dests; > + int new_perms; > + int ret = 0; > + > + ret = qcom_scm_prepare_mem_batch(table, srcvms, nr_src, > + destvms, destvms_perms, nr_dest, last_sgl, false); > + > + if (!ret) > + goto out; > + new_dests = QCOM_SCM_VMID_HLOS; We have the original srcvms. Will it always be HLOS? If so, then do we need to pass srcvms at all? > + new_perms = QCOM_SCM_PERM_EXEC | QCOM_SCM_PERM_WRITE | QCOM_SCM_PERM_READ; > + rb_ret = qcom_scm_prepare_mem_batch(table, destvms, nr_dest, &new_dests, > + &new_perms, nr_src, last_sgl, true); > + WARN_ON_ONCE(rb_ret); > +out: > + return ret; > +} > +EXPORT_SYMBOL_GPL(qcom_scm_assign_table); Who uses this function? > + > /** > * qcom_scm_ocmem_lock_available() - is OCMEM lock/unlock interface available > */ > diff --git a/include/linux/firmware/qcom/qcom_scm.h b/include/linux/firmware/qcom/qcom_scm.h > index ccaf28846054..abd675c7ef49 100644 > --- a/include/linux/firmware/qcom/qcom_scm.h > +++ b/include/linux/firmware/qcom/qcom_scm.h > @@ -8,6 +8,7 @@ > #include > #include > #include > +#include > > #include > > @@ -15,6 +16,8 @@ > #define QCOM_SCM_CPU_PWR_DOWN_L2_ON 0x0 > #define QCOM_SCM_CPU_PWR_DOWN_L2_OFF 0x1 > #define QCOM_SCM_HDCP_MAX_REQ_CNT 5 > +#define QCOM_SCM_MAX_BATCH_SECTION 32 > +#define QCOM_SCM_MAX_BATCH_SIZE SZ_2M > > struct qcom_scm_hdcp_req { > u32 addr; > @@ -93,6 +96,10 @@ int qcom_scm_mem_protect_video_var(u32 cp_start, u32 cp_size, > int qcom_scm_assign_mem(phys_addr_t mem_addr, size_t mem_sz, u64 *src, > const struct qcom_scm_vmperm *newvm, > unsigned int dest_cnt); > +int qcom_scm_assign_table(struct sg_table *table, > + u32 *srcvms, int nr_src, > + int *destvms, int *destvms_perms, > + int nr_dest); > > bool qcom_scm_ocmem_lock_available(void); > int qcom_scm_ocmem_lock(enum qcom_scm_ocmem_client id, u32 offset, u32 size, > -- > 2.34.1 >