From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 83821C433F5 for ; Mon, 11 Oct 2021 13:47:23 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 5874160E8B for ; Mon, 11 Oct 2021 13:47:23 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S234234AbhJKNtW (ORCPT ); Mon, 11 Oct 2021 09:49:22 -0400 Received: from foss.arm.com ([217.140.110.172]:55414 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S234566AbhJKNtW (ORCPT ); Mon, 11 Oct 2021 09:49:22 -0400 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id E7024101E; Mon, 11 Oct 2021 06:47:21 -0700 (PDT) Received: from [10.57.95.157] (unknown [10.57.95.157]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 0D9E93F694; Mon, 11 Oct 2021 06:47:19 -0700 (PDT) Subject: Re: [PATCH v7 1/9] iommu: Introduce a union to struct iommu_resv_region To: Shameerali Kolothum Thodi , Jon Nettleton Cc: linux-arm-kernel , ACPI Devel Maling List , Linux IOMMU , Linuxarm , Steven Price , "Guohanjun (Hanjun Guo)" , yangyicong , Sami Mujawar , Will Deacon , wanghuiqiang References: <20210805080724.480-1-shameerali.kolothum.thodi@huawei.com> <20210805080724.480-2-shameerali.kolothum.thodi@huawei.com> <9df40b8f09f6488382f25f419519a2fa@huawei.com> From: Robin Murphy Message-ID: Date: Mon, 11 Oct 2021 14:47:14 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; rv:78.0) Gecko/20100101 Thunderbird/78.14.0 MIME-Version: 1.0 In-Reply-To: <9df40b8f09f6488382f25f419519a2fa@huawei.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-GB Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: linux-acpi@vger.kernel.org On 2021-10-11 06:47, Shameerali Kolothum Thodi wrote: > > >> -----Original Message----- >> From: Jon Nettleton [mailto:jon@solid-run.com] >> Sent: 09 October 2021 07:58 >> To: Robin Murphy >> Cc: Shameerali Kolothum Thodi ; >> linux-arm-kernel ; ACPI Devel Maling >> List ; Linux IOMMU >> ; Linuxarm ; >> Steven Price ; Guohanjun (Hanjun Guo) >> ; yangyicong ; Sami >> Mujawar ; Will Deacon ; >> wanghuiqiang >> Subject: Re: [PATCH v7 1/9] iommu: Introduce a union to struct >> iommu_resv_region >> >> On Fri, Oct 8, 2021 at 2:14 PM Robin Murphy >> wrote: >>> >>> On 2021-08-05 09:07, Shameer Kolothum wrote: >>>> A union is introduced to struct iommu_resv_region to hold any >>>> firmware specific data. This is in preparation to add support for >>>> IORT RMR reserve regions and the union now holds the RMR specific >>>> information. >>>> >>>> Signed-off-by: Shameer Kolothum >>>> >>>> --- >>>> include/linux/iommu.h | 11 +++++++++++ >>>> 1 file changed, 11 insertions(+) >>>> >>>> diff --git a/include/linux/iommu.h b/include/linux/iommu.h index >>>> 32d448050bf7..bd0e4641c569 100644 >>>> --- a/include/linux/iommu.h >>>> +++ b/include/linux/iommu.h >>>> @@ -114,6 +114,13 @@ enum iommu_resv_type { >>>> IOMMU_RESV_SW_MSI, >>>> }; >>>> >>>> +struct iommu_iort_rmr_data { >>>> +#define IOMMU_RMR_REMAP_PERMITTED (1 << 0) >>>> + u32 flags; >>>> + u32 sid; /* Stream Id associated with RMR entry */ >>>> + void *smmu; /* Associated IORT SMMU node pointer */ >>>> +}; >>> >>> Do we really need to duplicate all this data? AFAICS we could just >>> save the acpi_iort_rmr pointer in the iommu_resv_region (with a >>> forward declaration here if necessary) and defer parsing its actual >>> mappings until the point where we can directly consume the results. >> >> From earlier discussions on this patchset, the original goal was also for >> device-tree mechanisms to be able to hook into this code to support similar >> RMR's and SMMU initialization, just not through the ACPI / IORT path. > > Yes. IIRC, there were some earlier attempts to have DT support for reserved regions > and there was a suggestion to provide generic interfaces so that when DT solution > comes up it is easier to add the support. OK, but in that case why is every single part of it IORT-specific in either name, description or function? Regardless, s/acpi_iort_rmr/original firmware descriptor of whatever variety/ and my comment still stands. If a firmware-specific structure is still going to exist to begin with, then what do we gain from interpreting details earlier than needed and wasting memory storing copies of them? This isn't something we're looking up hundreds of times per second and need to cache in some more efficient format. Furthermore, it seems unlikely that the eventual DT solution would end up being semantically identical to IORT RMRs, so there's every possibility that the One True Abstract Structure would need changing to work for another firmware implementation anyway. Heck, it might not even fit future IORT if it becomes permissible for multiple StreamIDs to share a single RMR descriptor. Thanks, Robin. From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 9357CC433F5 for ; Mon, 11 Oct 2021 13:47:29 +0000 (UTC) Received: from smtp2.osuosl.org (smtp2.osuosl.org [140.211.166.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 3BC1160E8B for ; Mon, 11 Oct 2021 13:47:29 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 3BC1160E8B Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=arm.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=lists.linux-foundation.org Received: from localhost (localhost [127.0.0.1]) by smtp2.osuosl.org (Postfix) with ESMTP id EFAC94033B; Mon, 11 Oct 2021 13:47:28 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org Received: from smtp2.osuosl.org ([127.0.0.1]) by localhost (smtp2.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LWWhDPdNRv2F; Mon, 11 Oct 2021 13:47:26 +0000 (UTC) Received: from lists.linuxfoundation.org (lf-lists.osuosl.org [140.211.9.56]) by smtp2.osuosl.org (Postfix) with ESMTPS id 875994021A; Mon, 11 Oct 2021 13:47:25 +0000 (UTC) Received: from lf-lists.osuosl.org (localhost [127.0.0.1]) by lists.linuxfoundation.org (Postfix) with ESMTP id 587EBC000F; Mon, 11 Oct 2021 13:47:25 +0000 (UTC) Received: from smtp4.osuosl.org (smtp4.osuosl.org [IPv6:2605:bc80:3010::137]) by lists.linuxfoundation.org (Postfix) with ESMTP id 4303DC000D for ; Mon, 11 Oct 2021 13:47:24 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp4.osuosl.org (Postfix) with ESMTP id 3203040457 for ; Mon, 11 Oct 2021 13:47:24 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org Received: from smtp4.osuosl.org ([127.0.0.1]) by localhost (smtp4.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Dw-sCvOtGRdt for ; Mon, 11 Oct 2021 13:47:22 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.8.0 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by smtp4.osuosl.org (Postfix) with ESMTP id CFE1240338 for ; Mon, 11 Oct 2021 13:47:22 +0000 (UTC) Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id E7024101E; Mon, 11 Oct 2021 06:47:21 -0700 (PDT) Received: from [10.57.95.157] (unknown [10.57.95.157]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 0D9E93F694; Mon, 11 Oct 2021 06:47:19 -0700 (PDT) Subject: Re: [PATCH v7 1/9] iommu: Introduce a union to struct iommu_resv_region To: Shameerali Kolothum Thodi , Jon Nettleton References: <20210805080724.480-1-shameerali.kolothum.thodi@huawei.com> <20210805080724.480-2-shameerali.kolothum.thodi@huawei.com> <9df40b8f09f6488382f25f419519a2fa@huawei.com> From: Robin Murphy Message-ID: Date: Mon, 11 Oct 2021 14:47:14 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; rv:78.0) Gecko/20100101 Thunderbird/78.14.0 MIME-Version: 1.0 In-Reply-To: <9df40b8f09f6488382f25f419519a2fa@huawei.com> Content-Language: en-GB Cc: Linuxarm , Steven Price , ACPI Devel Maling List , Linux IOMMU , wanghuiqiang , "Guohanjun \(Hanjun Guo\)" , yangyicong , Sami Mujawar , Will Deacon , linux-arm-kernel X-BeenThere: iommu@lists.linux-foundation.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Development issues for Linux IOMMU support List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Errors-To: iommu-bounces@lists.linux-foundation.org Sender: "iommu" On 2021-10-11 06:47, Shameerali Kolothum Thodi wrote: > > >> -----Original Message----- >> From: Jon Nettleton [mailto:jon@solid-run.com] >> Sent: 09 October 2021 07:58 >> To: Robin Murphy >> Cc: Shameerali Kolothum Thodi ; >> linux-arm-kernel ; ACPI Devel Maling >> List ; Linux IOMMU >> ; Linuxarm ; >> Steven Price ; Guohanjun (Hanjun Guo) >> ; yangyicong ; Sami >> Mujawar ; Will Deacon ; >> wanghuiqiang >> Subject: Re: [PATCH v7 1/9] iommu: Introduce a union to struct >> iommu_resv_region >> >> On Fri, Oct 8, 2021 at 2:14 PM Robin Murphy >> wrote: >>> >>> On 2021-08-05 09:07, Shameer Kolothum wrote: >>>> A union is introduced to struct iommu_resv_region to hold any >>>> firmware specific data. This is in preparation to add support for >>>> IORT RMR reserve regions and the union now holds the RMR specific >>>> information. >>>> >>>> Signed-off-by: Shameer Kolothum >>>> >>>> --- >>>> include/linux/iommu.h | 11 +++++++++++ >>>> 1 file changed, 11 insertions(+) >>>> >>>> diff --git a/include/linux/iommu.h b/include/linux/iommu.h index >>>> 32d448050bf7..bd0e4641c569 100644 >>>> --- a/include/linux/iommu.h >>>> +++ b/include/linux/iommu.h >>>> @@ -114,6 +114,13 @@ enum iommu_resv_type { >>>> IOMMU_RESV_SW_MSI, >>>> }; >>>> >>>> +struct iommu_iort_rmr_data { >>>> +#define IOMMU_RMR_REMAP_PERMITTED (1 << 0) >>>> + u32 flags; >>>> + u32 sid; /* Stream Id associated with RMR entry */ >>>> + void *smmu; /* Associated IORT SMMU node pointer */ >>>> +}; >>> >>> Do we really need to duplicate all this data? AFAICS we could just >>> save the acpi_iort_rmr pointer in the iommu_resv_region (with a >>> forward declaration here if necessary) and defer parsing its actual >>> mappings until the point where we can directly consume the results. >> >> From earlier discussions on this patchset, the original goal was also for >> device-tree mechanisms to be able to hook into this code to support similar >> RMR's and SMMU initialization, just not through the ACPI / IORT path. > > Yes. IIRC, there were some earlier attempts to have DT support for reserved regions > and there was a suggestion to provide generic interfaces so that when DT solution > comes up it is easier to add the support. OK, but in that case why is every single part of it IORT-specific in either name, description or function? Regardless, s/acpi_iort_rmr/original firmware descriptor of whatever variety/ and my comment still stands. If a firmware-specific structure is still going to exist to begin with, then what do we gain from interpreting details earlier than needed and wasting memory storing copies of them? This isn't something we're looking up hundreds of times per second and need to cache in some more efficient format. Furthermore, it seems unlikely that the eventual DT solution would end up being semantically identical to IORT RMRs, so there's every possibility that the One True Abstract Structure would need changing to work for another firmware implementation anyway. Heck, it might not even fit future IORT if it becomes permissible for multiple StreamIDs to share a single RMR descriptor. Thanks, Robin. _______________________________________________ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 1A1D8C433F5 for ; Mon, 11 Oct 2021 13:51:22 +0000 (UTC) Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id C590A61076 for ; Mon, 11 Oct 2021 13:51:21 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org C590A61076 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=arm.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender:Content-Type: Content-Transfer-Encoding:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:Date:Message-ID:From: References:Cc:To:Subject:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=yVl0c6t0QBeR4GGKlsqNCrg7TOm0TGLqTFfYvE+u32o=; b=3SLcOzjyGH/0PclVXn/rWKKeON TQGwAWi80V+V0slal2af0VV3GltAHAHNM3uDIREZAFVC+7e+bFETzfp8GC3O0ONbYWBH5x8Yb8JYM /IVOad/apH12G1i6sOiOEC4AYNB35R+5tbtIcmitNw9yIDqsyabOrUxN1bs/x0UjORXAKjkZLtg+B BOCTfD8u8cS+FXRP8KE1i4lk7sAJuzMJhBUVw3J/yDPoIdUjwu3XmFQT350IAHrsyoxsQKHe8DqrD iW5R4fSDtUEISW7WRYxChVQE620ajRpw6sjE/J9CBPmpEcUsnrN/TGJznuoWASNxgn4fNOMxlk2Nf Wa4qnWmw==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1mZvfZ-009czz-Si; Mon, 11 Oct 2021 13:48:46 +0000 Received: from foss.arm.com ([217.140.110.172]) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1mZveM-009cQm-SF for linux-arm-kernel@lists.infradead.org; Mon, 11 Oct 2021 13:47:32 +0000 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id E7024101E; Mon, 11 Oct 2021 06:47:21 -0700 (PDT) Received: from [10.57.95.157] (unknown [10.57.95.157]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 0D9E93F694; Mon, 11 Oct 2021 06:47:19 -0700 (PDT) Subject: Re: [PATCH v7 1/9] iommu: Introduce a union to struct iommu_resv_region To: Shameerali Kolothum Thodi , Jon Nettleton Cc: linux-arm-kernel , ACPI Devel Maling List , Linux IOMMU , Linuxarm , Steven Price , "Guohanjun (Hanjun Guo)" , yangyicong , Sami Mujawar , Will Deacon , wanghuiqiang References: <20210805080724.480-1-shameerali.kolothum.thodi@huawei.com> <20210805080724.480-2-shameerali.kolothum.thodi@huawei.com> <9df40b8f09f6488382f25f419519a2fa@huawei.com> From: Robin Murphy Message-ID: Date: Mon, 11 Oct 2021 14:47:14 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; rv:78.0) Gecko/20100101 Thunderbird/78.14.0 MIME-Version: 1.0 In-Reply-To: <9df40b8f09f6488382f25f419519a2fa@huawei.com> Content-Language: en-GB X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20211011_064731_085280_9FBAD239 X-CRM114-Status: GOOD ( 20.69 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On 2021-10-11 06:47, Shameerali Kolothum Thodi wrote: > > >> -----Original Message----- >> From: Jon Nettleton [mailto:jon@solid-run.com] >> Sent: 09 October 2021 07:58 >> To: Robin Murphy >> Cc: Shameerali Kolothum Thodi ; >> linux-arm-kernel ; ACPI Devel Maling >> List ; Linux IOMMU >> ; Linuxarm ; >> Steven Price ; Guohanjun (Hanjun Guo) >> ; yangyicong ; Sami >> Mujawar ; Will Deacon ; >> wanghuiqiang >> Subject: Re: [PATCH v7 1/9] iommu: Introduce a union to struct >> iommu_resv_region >> >> On Fri, Oct 8, 2021 at 2:14 PM Robin Murphy >> wrote: >>> >>> On 2021-08-05 09:07, Shameer Kolothum wrote: >>>> A union is introduced to struct iommu_resv_region to hold any >>>> firmware specific data. This is in preparation to add support for >>>> IORT RMR reserve regions and the union now holds the RMR specific >>>> information. >>>> >>>> Signed-off-by: Shameer Kolothum >>>> >>>> --- >>>> include/linux/iommu.h | 11 +++++++++++ >>>> 1 file changed, 11 insertions(+) >>>> >>>> diff --git a/include/linux/iommu.h b/include/linux/iommu.h index >>>> 32d448050bf7..bd0e4641c569 100644 >>>> --- a/include/linux/iommu.h >>>> +++ b/include/linux/iommu.h >>>> @@ -114,6 +114,13 @@ enum iommu_resv_type { >>>> IOMMU_RESV_SW_MSI, >>>> }; >>>> >>>> +struct iommu_iort_rmr_data { >>>> +#define IOMMU_RMR_REMAP_PERMITTED (1 << 0) >>>> + u32 flags; >>>> + u32 sid; /* Stream Id associated with RMR entry */ >>>> + void *smmu; /* Associated IORT SMMU node pointer */ >>>> +}; >>> >>> Do we really need to duplicate all this data? AFAICS we could just >>> save the acpi_iort_rmr pointer in the iommu_resv_region (with a >>> forward declaration here if necessary) and defer parsing its actual >>> mappings until the point where we can directly consume the results. >> >> From earlier discussions on this patchset, the original goal was also for >> device-tree mechanisms to be able to hook into this code to support similar >> RMR's and SMMU initialization, just not through the ACPI / IORT path. > > Yes. IIRC, there were some earlier attempts to have DT support for reserved regions > and there was a suggestion to provide generic interfaces so that when DT solution > comes up it is easier to add the support. OK, but in that case why is every single part of it IORT-specific in either name, description or function? Regardless, s/acpi_iort_rmr/original firmware descriptor of whatever variety/ and my comment still stands. If a firmware-specific structure is still going to exist to begin with, then what do we gain from interpreting details earlier than needed and wasting memory storing copies of them? This isn't something we're looking up hundreds of times per second and need to cache in some more efficient format. Furthermore, it seems unlikely that the eventual DT solution would end up being semantically identical to IORT RMRs, so there's every possibility that the One True Abstract Structure would need changing to work for another firmware implementation anyway. Heck, it might not even fit future IORT if it becomes permissible for multiple StreamIDs to share a single RMR descriptor. Thanks, Robin. _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel