From mboxrd@z Thu Jan 1 00:00:00 1970 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 04932331EBB for ; Wed, 10 Jun 2026 14:27:58 +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=1781101681; cv=none; b=tqnCzApDGiTMT5S/+6Y4PXANgxaZpPqUUDRLSR+kwosH85bJK6LcWD0KgbaMaIKL013J3haS/m52CrxWzXcGTsR0XGH4jOhjkuty7T0ao75E2h1xpCv2Br8f8T6qrkn0uYisXSc76xqlxLNoiPQpq+GcQ8y9o6Tzh6O8z9d696M= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1781101681; c=relaxed/simple; bh=ZDMr1KkMuid1/5JtT6zI9SV1IV3OBy8MAYDcq/h+gVc=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=opI4fIziMxqiz8wH+RFKnvmdhQjmSvCpBdOrmXByvAnUuNN4YBLqVgDvvDvs8NQvHbkVOh3mwSrohOulSl7b6cLQR9wEqKghApnI22NeSRB0RJ9Kuhj+cQDdvRjhTkSXqfbSoTSUa7N8kYxV8F38XUscO9/FlJkJsmEtxBEvPRY= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=oss.qualcomm.com; spf=pass smtp.mailfrom=oss.qualcomm.com; dkim=pass (2048-bit key) header.d=qualcomm.com header.i=@qualcomm.com header.b=hUuafbk6; dkim=pass (2048-bit key) header.d=oss.qualcomm.com header.i=@oss.qualcomm.com header.b=HkX4Llzx; arc=none smtp.client-ip=205.220.180.131 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=oss.qualcomm.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=oss.qualcomm.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=qualcomm.com header.i=@qualcomm.com header.b="hUuafbk6"; dkim=pass (2048-bit key) header.d=oss.qualcomm.com header.i=@oss.qualcomm.com header.b="HkX4Llzx" Received: from pps.filterd (m0279868.ppops.net [127.0.0.1]) by mx0a-0031df01.pphosted.com (8.18.1.11/8.18.1.11) with ESMTP id 65ACCHhA1472577 for ; Wed, 10 Jun 2026 14:27:57 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=qualcomm.com; h= cc:content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to; s=qcppdkim1; bh= ZDMr1KkMuid1/5JtT6zI9SV1IV3OBy8MAYDcq/h+gVc=; b=hUuafbk6XbDXfklH nDxKc46oRgpXMyGRmH4nTXsxLZWIQXLz7nnY8hvoz7Ab/CVbBAY++3hawv19zWM4 eqWns/hzxNX79laWU1kXFSZ9XVVHzed/rCck4nOko6cFkyaACpcnBuW2ERcgEVy2 iCOWg3HhoKqehPRk5k/RIwgK4d1X8P8zDNyCCRZK9a1YGQPCD4EgldRZ6TjR0kxb QfFxbNS5TRZ7Wh696BUFrHDTTONhcgJ5nNtYCjvkw5BT5DOtNZDPXVkbd1OuzM3G ywi8Hvnr2uYFeEOGQAAnM0Fe4Jq2IN4OjSS4O3yLNmxT6opxfwTHQPrV0tV7Irh2 JsKeOA== Received: from mail-pj1-f69.google.com (mail-pj1-f69.google.com [209.85.216.69]) by mx0a-0031df01.pphosted.com (PPS) with ESMTPS id 4eq0kda9qs-1 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NOT) for ; Wed, 10 Jun 2026 14:27:57 +0000 (GMT) Received: by mail-pj1-f69.google.com with SMTP id 98e67ed59e1d1-36e09ec696aso11707206a91.0 for ; Wed, 10 Jun 2026 07:27:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oss.qualcomm.com; s=google; t=1781101676; x=1781706476; darn=vger.kernel.org; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=ZDMr1KkMuid1/5JtT6zI9SV1IV3OBy8MAYDcq/h+gVc=; b=HkX4Llzxia7ojWCwfHvLkb2A/g8GgjH+CRuizqomhFDikVok3kAf4o8Z4j5TbaJ51K OB+8MsAztmtEBphW16ODDYkPex+/OowQQy1ekQkMH6gaZtVBItUh6wxfD9+zRn/sAZyO usvMtOAYxR3ec6MOMMrTldha+cpZp0xV2++fQw+rh30i63kVyyC6+6xzaU0ErPBlflxH tvFEmkXk5oqp8nF3fTHaBebPXpB6LBgR4GOtwqmjUmE4dfMLFSrUumaw9ahSHZm8kt93 yDrihXg7nMCuXH2wITaDuZBRmzQ/CPTiVVJmn4HnLa8l0+AAnfF1MAEjb/rRYnkM6wdy oeoA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1781101676; x=1781706476; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :x-gm-gg:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=ZDMr1KkMuid1/5JtT6zI9SV1IV3OBy8MAYDcq/h+gVc=; b=qB8FSJ0lhg0w4ubNcIIWXwTvf6WpBLv6y8aCwUyQEj8PYQjYZzz1UPTNT6m95j9rPi KEVPqto9rL2hZSQYavteK1hiJita2S7IW90nNaYcdv2ruNqy0fOAHhnDhihbw56mN4Uv TG1DNHipNUwTf1eaTun8d717OJ+EpESqobt5LyItdZj4xTqv71yYQM14+eIAZUuO/tgp hB/JnmzMy2zDkRdqLlFQKYZ+H0cLhOVdWt0SJYpGPXC2ZiTYq9ANReN3GJlVsjKrKnb5 vO1s8eSm+I07+BkCCYs4B+3U3knisyx8F6zxkXy/uAsO++sQ6L0uBYptjOpcoVZXmfR/ WUUw== X-Forwarded-Encrypted: i=1; AFNElJ8k7i0GYDi7q1MCX/9XaaLSiPOzS0AtAvBcS/iDvbzI2l8bKWDvT7FIEL4LfP+gJ99dHgpk50in2b+jYIQ=@vger.kernel.org X-Gm-Message-State: AOJu0Yy4S7vZro0qV5zT6GubMqJZZIi1DTDMq48+O0u9q+0D/OWwD+Y8 gOXovaeistJU0BWk9ad50AFkVS9D4O/QANePGzkRKbDFCrQUe/SBTS3cBcw13k3WCic+DKBu3U+ HxgD7jsWCC/W6DnI05F1DepP5Zmc7DD3NNHVBvlw3dUbgiXpl8T+21IC0t3RjRaqQSHY= X-Gm-Gg: Acq92OEexblgm4ilu+4NX3ittn2elStsJUA4II6Tk+PX1oQxBjtdi4m4zuahO01gvXM MZB02RheUGc5RVqb6kLgqWnPFZMalxg2JOAYmPlFyM0Oo3G/2EiRE8Lcv1qgRPlIuQK3zP1VaX/ 0fkoqt4L7bFkUSPwMl5oi23rWkBSWJlZJD0JBhBnmPOCHRIYspC2jW0IhQtcMKIwfnIeK1AL3SG 2mJQ+IEq2C8FQzef/kbsoK3mWSOv42rdtSdeDh8FGSu8KpoANJV9Bz2At2Fwz8LjtYWwoBi8d3S jw7mCRjuZkOpIvhj4JJsavSp6PjSOYZZxCz7pDqqrAb40LtqaupSAudJnUG/Tj+ske+uBe0T9xu 6SFIgSuQpxdA2NFGJd3EMomuUeCxwljh+EpHPvd/H1+PxBiWAABoDUUFDBvjbRjqv X-Received: by 2002:a17:90b:5106:b0:36b:afa0:c53d with SMTP id 98e67ed59e1d1-370ee82fd0dmr27039650a91.2.1781101676369; Wed, 10 Jun 2026 07:27:56 -0700 (PDT) X-Received: by 2002:a17:90b:5106:b0:36b:afa0:c53d with SMTP id 98e67ed59e1d1-370ee82fd0dmr27039612a91.2.1781101675823; Wed, 10 Jun 2026 07:27:55 -0700 (PDT) Received: from [10.206.105.200] ([202.46.23.25]) by smtp.gmail.com with ESMTPSA id 98e67ed59e1d1-37645a2c6a9sm1984838a91.1.2026.06.10.07.27.52 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 10 Jun 2026 07:27:55 -0700 (PDT) Message-ID: Date: Wed, 10 Jun 2026 19:57:50 +0530 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101 Thunderbird/102.8.0 Subject: Re: [PATCH] dma-iommu: Introduce API to reserve IOVA regions for dynamically created devices To: Robin Murphy , joro@8bytes.org, will@kernel.org, m.szyprowski@samsung.com Cc: iommu@lists.linux.dev, linux-kernel@vger.kernel.org, vikash.garodia@oss.qualcomm.com, dikshita.agarwal@oss.qualcomm.com References: <20260119054936.3350128-1-busanna.reddy@oss.qualcomm.com> Content-Language: en-US From: Vishnu Reddy In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Authority-Analysis: v=2.4 cv=TeamcxQh c=1 sm=1 tr=0 ts=6a29746d cx=c_pps a=vVfyC5vLCtgYJKYeQD43oA==:117 a=ZePRamnt/+rB5gQjfz0u9A==:17 a=IkcTkHD0fZMA:10 a=FelO9ux0wxsA:10 a=s4-Qcg_JpJYA:10 a=VkNPw1HP01LnGYTKEx00:22 a=u7WPNUs3qKkmUXheDGA7:22 a=ZpdpYltYx_vBUK5n70dp:22 a=e5mUnYsNAAAA:8 a=VwQbUJbxAAAA:8 a=EUspDBNiAAAA:8 a=ALB7cA6TA5vMt6cBXkgA:9 a=3ZKOabzyN94A:10 a=QEXdDO2ut3YA:10 a=rl5im9kqc5Lf4LNbBjHf:22 a=Vxmtnl_E_bksehYqCbjh:22 X-Proofpoint-GUID: TuxkYOW9fchfNSTtiOpH6JZSZFXNI_w5 X-Proofpoint-ORIG-GUID: TuxkYOW9fchfNSTtiOpH6JZSZFXNI_w5 X-Proofpoint-Spam-Details-Enc: AW1haW4tMjYwNjEwMDEzOCBTYWx0ZWRfX5KGT1Wdtroks PJebboWkaCMgUdxGydskERfproATMA5gvSX2bU4L80H8IT/hKALBu1TUYxf5XJ9AFS8V+G9aJkP Z5Lj3ObOyrF68a5hlPa8jCs0dcnMhglvwbdmqZWOmVEA1jdBV0tcm3VjriHjcdq6aop3ybgu8W8 H/meg8QmDx3isOB7V0+FXKTlz7hd8MPu5AV+2E1Rzw8yn41TjMHCA2+wgmJxoa7Sj1gXV5ZT/P+ D1COXoUKGm+l6SYD8d0s6hHb+JQWptwBBoD9frKf6Pm7QAsB3Bb+8DipMAiOwzRbl2C8JjEPnZh 0pFzMCEl1u9VoJ2kRyC4GxgG1ifgmZAgJuhe2GUmh6aB5IBj5W5DqzpP26zSysLbPvOxwHUfsUV hL6t4CSNkQodSieIyzTabbRsW6h3tebVzdB/FNzieI38nKPXm5ph5tmi7Tucz4SMFeM+TQMAk0L bVfGNCwWUT5zJQ2rW9w== X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.293,Aquarius:18.0.1143,Hydra:6.1.125,FMLib:17.12.100.49 definitions=2026-06-10_03,2026-06-09_02,2025-10-01_01 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 lowpriorityscore=0 suspectscore=0 malwarescore=0 phishscore=0 spamscore=0 impostorscore=0 clxscore=1015 priorityscore=1501 bulkscore=0 adultscore=0 classifier=typeunknown authscore=0 authtc= authcc= route=outbound adjust=0 reason=mlx scancount=1 engine=8.22.0-2605210000 definitions=main-2606100138 On 1/19/2026 7:43 PM, Robin Murphy wrote: > On 19/01/2026 5:49 am, Vishnu Reddy wrote: >> Drivers can create child devices dynamically. These child devices often >> inherit parent device tree node, including its reserved iommu-address >> ranges. > > Which frankly sounds entirely wrong. If there are distinct devices with > distinct hardware properties, then they should be properly described as such, > and handled by a proper bus driver. And if different devices have different > DMA restrictions, that should be described by "dma-ranges", not by abusing > reserved regions. > Hi Robin, The VPU is a single hardware unit, but internally it consists of multiple functional blocks. Each block has its own distinct Stream ID (SID) and operates with a different IOVA range requirement:   +--------------------------------------------------+   |                  VPU Hardware                    |   |                                                  |   |  +------------+   SID-0   IOVA: 600MB - 3500MB   |   |  |  Block 0   |                                  |   |  +------------+                                  |   |                                                  |   |  +------------+   SID-1   IOVA: 0MB  - 3500MB    |   |  |  Block 1   |                                  |   |  +------------+                                  |   |                                                  |   |  +------------+   SID-2   IOVA: 16MB - 600MB     |   |  |  Block 2   |                                  |   |  +------------+                                  |   +--------------------------------------------------+ Each Stream ID maps to a distinct IOMMU context bank, and each context bank enforces a different IOVA range. The upper boundary can be enforced via dma_set_mask_and_coherent. However, enforcing the lower boundary (e.g., blocking 0 to 600MB for Block 0, and 0 to 16MB for Block 2) requires explicit IOVA reservation, which is what dma_iova_set_resv_region() provides in this patch. These are synthetic child devices created at runtime and do not have their own of_node. Inheriting the parent of_node might not be the correct way. A crash was observed on one of the platforms due to the absence of reserved regions. This API would help avoid such crashes by allowing drivers to explicitly reserve the restricted IOVA range. https://gitlab.freedesktop.org/drm/msm/-/work_items/100 Thanks, Vishnu Reddy. > Thanks, > Robin. > >> While device tree can declare the multiple iommu-address ranges, >> they still apply uniformly to any child inheriting the parent OF node. >> >> This creates a limitation when child requires a different iommu-address >> range than its parent, as device tree cannot express the reservation per >> child. >> >> Example layout and use case: >> ---------------------------- >> A multimedia subsystem with multiple child devices and distinct ranges: >> >>      +-----------------------------------------------------------+ >>      | Device A reserved region (256 MB)                         | >>      | 0x00000000 - 0x10000000                                   | >>      +-----------------------------------------------------------+ >>      | Device B reserved region (512 MB)                         | >>      | 0x00000000 - 0x20000000                                   | >>      +-----------------------------------------------------------+ >>      | Device C reserved region (600 MB)                         | >>      | 0x00000000 - 0x25800000                                   | >>      +-----------------------------------------------------------+ >>      | Other reserved regions                                    | >>      +-----------------------------------------------------------+ >> >> If we add Device C's reserved range (0x0 to 0x025800000) into iommu >> address range into device tree and assign that OF node to Device B >> and C, it wastes memory: >> - Device A wastes ~344 MB >> - Device B wastes ~88 MB >> >> To avoid this, drivers can use the introduced API to set their device >> specific IOVA region at runtime, ensuring the DMA mapping without >> unnecessary address space reservation. >> >> Signed-off-by: Vishnu Reddy >> Link: >> https://lore.kernel.org/all/20251220023555.3017456-1-busanna.reddy@oss.qualcomm.com/ >> --- >>   drivers/iommu/dma-iommu.c   | 44 +++++++++++++++++++++++++++++++++++++ >>   include/linux/dma-mapping.h |  7 ++++++ >>   2 files changed, 51 insertions(+) >> >> diff --git a/drivers/iommu/dma-iommu.c b/drivers/iommu/dma-iommu.c >> index aeaf8fad985c3..baee119e1c277 100644 >> --- a/drivers/iommu/dma-iommu.c >> +++ b/drivers/iommu/dma-iommu.c >> @@ -1743,6 +1743,50 @@ size_t iommu_dma_max_mapping_size(struct device *dev) >>       return SIZE_MAX; >>   } >>   +/** >> + * dma_iova_set_resv_region - Set a reserved region in the IOVA space >> + * @dev: Device to set the reserved region for >> + * @start: Start of the reserved region >> + * @length: Length of the reserved region >> + * >> + * This function enables drivers to set device specific reservations at >> + * runtime, which is particularly useful for dynamically created child >> + * devices that requires distinct IOVA ranges than parent. >> + * >> + * Returns: >> + *  0        - Success >> + *  -ENODEV  - No valid IOMMU DMA domain for the device >> + *  -EINVAL  - Invalid domain or cookie type for this operation >> + *  -ENOMEM  - Failed to reserve the requested range >> + */ >> +int dma_iova_set_resv_region(struct device *dev, unsigned long start, >> +                 unsigned long length) >> +{ >> +    struct iommu_dma_cookie *cookie; >> +    struct iommu_domain *domain; >> +    struct iova_domain *iovad; >> +    unsigned long lo, hi; >> + >> +    domain = iommu_get_dma_domain(dev); >> +    if (!domain || domain->type != IOMMU_DOMAIN_DMA) >> +        return -ENODEV; >> + >> +    cookie = domain->iova_cookie; >> +    if (!cookie || domain->cookie_type != IOMMU_COOKIE_DMA_IOVA) >> +        return -EINVAL; >> + >> +    iovad = &cookie->iovad; >> + >> +    lo = iova_pfn(iovad, start); >> +    hi = iova_pfn(iovad, start + length - 1); >> + >> +    if (!reserve_iova(iovad, lo, hi)) >> +        return -ENOMEM; >> + >> +    return 0; >> +} >> +EXPORT_SYMBOL_GPL(dma_iova_set_resv_region); >> + >>   /** >>    * dma_iova_try_alloc - Try to allocate an IOVA space >>    * @dev: Device to allocate the IOVA space for >> diff --git a/include/linux/dma-mapping.h b/include/linux/dma-mapping.h >> index 29973baa05816..75b65160a37f3 100644 >> --- a/include/linux/dma-mapping.h >> +++ b/include/linux/dma-mapping.h >> @@ -347,6 +347,8 @@ static inline bool dma_use_iova(struct dma_iova_state >> *state) >>       return state->__size != 0; >>   } >>   +int dma_iova_set_resv_region(struct device *dev, unsigned long start, >> +                 unsigned long length); >>   bool dma_iova_try_alloc(struct device *dev, struct dma_iova_state *state, >>           phys_addr_t phys, size_t size); >>   void dma_iova_free(struct device *dev, struct dma_iova_state *state); >> @@ -366,6 +368,11 @@ static inline bool dma_use_iova(struct dma_iova_state >> *state) >>   { >>       return false; >>   } >> +static inline int dma_iova_set_resv_region(struct device *dev, unsigned long >> start, >> +                       unsigned long length) >> +{ >> +    return -ENODEV; >> +} >>   static inline bool dma_iova_try_alloc(struct device *dev, >>           struct dma_iova_state *state, phys_addr_t phys, size_t size) >>   { >