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 X-Spam-Level: X-Spam-Status: No, score=-3.8 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id E7D7EC433EF for ; Thu, 16 Sep 2021 07:52:51 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id BB0BB610A4 for ; Thu, 16 Sep 2021 07:52:51 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231305AbhIPHyI (ORCPT ); Thu, 16 Sep 2021 03:54:08 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:40598 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S234767AbhIPHyH (ORCPT ); Thu, 16 Sep 2021 03:54:07 -0400 Received: from mail-ed1-x52e.google.com (mail-ed1-x52e.google.com [IPv6:2a00:1450:4864:20::52e]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 52795C061574 for ; Thu, 16 Sep 2021 00:52:47 -0700 (PDT) Received: by mail-ed1-x52e.google.com with SMTP id j13so13365664edv.13 for ; Thu, 16 Sep 2021 00:52:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=solid-run-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=ODMKOAGqD4ItUpYtqxdJhUq4QAGfb72lqYAxg7uVUGE=; b=chtAbpIChinWBdEU1gL0ntvM9+0WUqRdjW5xXbWXxve4i322V8dGlTe9RiiuK3Ky4X c4akEZ5ZtlGIE4Oq5bKagynGKAzDDWLhPD16IaRA87RHwvszd2Dd9BcUfbSoGsR9eW23 jCna1ptofFWrFzh1WoFFdzasf5ZaWs3oaf2rCLIudjsKhBAEHN4skc61+FZLbHn63DN0 rNGf+UyI8WD/28M5HK/XKfP5ioyaoiYkqVrB9g+dtXaUnXSgWMUJPcNDt4JNfSsTxCBj blBr5Gzj1Bep+7R7sSd1nskzkOQz0mQNLiq9MFxbbycGsJJRkg9ZK3NBERnWlMz9RRRQ voAg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=ODMKOAGqD4ItUpYtqxdJhUq4QAGfb72lqYAxg7uVUGE=; b=8OCxSyoUCo7ETrKcCWq+j5+ZQzbEJGcMm3Zh1p5ielzT+wZ5xRZrZa02eqbDItpEJy xKBEww5oNQcsI5zYVZe+eCu512ggRhnme8WoLC6AyZ8NikWg+tZ3m07BcPNAvfQq+R4i Yh0JVhblyhMbKBS36TmvD2gLNNO8QxBjk4rxbHaqfNIn5RvInUs4VhPH1HJ0G/bJuajJ l30r+nQOqH0xY+I5AV8ep3/o7xsWRgqNBYrsPO/hU1yWC+XCTiOhcgLm3+c9FedVN1u0 JKQmX+dTQYz3FiH0rW3a32xk4twpjMOyQJHx6MFNfw10wx/ikeAcGS3tfju9BG7ZY8JO dVIA== X-Gm-Message-State: AOAM533XOfqsuQyqVycPHxsxltECo05VI40ORF/mobI6WwM7j4IM5X3o l3j6lxr/AHdwptK0ulH5tJwpgGI2DO5uNqEr0hx+Ww== X-Google-Smtp-Source: ABdhPJyKDvyZKYCRYuxgjitZgDg2r13roWQBKzWOY1Mt3prlNydzDybS+gDSrHtYZ6S21wAVeWfjewN4V0nE2cFjwQw= X-Received: by 2002:a17:906:1341:: with SMTP id x1mr4645297ejb.277.1631778765895; Thu, 16 Sep 2021 00:52:45 -0700 (PDT) MIME-Version: 1.0 References: <20210805080724.480-1-shameerali.kolothum.thodi@huawei.com> <20210805080724.480-3-shameerali.kolothum.thodi@huawei.com> <20210805160319.GB23085@lpieralisi> <5d9bebdf-6eb5-49a0-2e8f-490df2d6754d@arm.com> In-Reply-To: From: Jon Nettleton Date: Thu, 16 Sep 2021 09:52:08 +0200 Message-ID: Subject: Re: [PATCH v7 2/9] ACPI/IORT: Add support for RMR node parsing To: Shameerali Kolothum Thodi Cc: Robin Murphy , Lorenzo Pieralisi , Laurentiu Tudor , linux-arm-kernel , ACPI Devel Maling List , Linux IOMMU , Joerg Roedel , Will Deacon , wanghuiqiang , "Guohanjun (Hanjun Guo)" , Steven Price , Sami Mujawar , Eric Auger , yangyicong Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-acpi@vger.kernel.org On Thu, Sep 16, 2021 at 9:26 AM Shameerali Kolothum Thodi wrote: > > > > > -----Original Message----- > > From: Jon Nettleton [mailto:jon@solid-run.com] > > Sent: 06 September 2021 20:51 > > To: Robin Murphy > > Cc: Lorenzo Pieralisi ; Shameerali Kolothum Thodi > > ; Laurentiu Tudor > > ; linux-arm-kernel > > ; ACPI Devel Maling List > > ; Linux IOMMU > > ; Linuxarm ; > > Joerg Roedel ; Will Deacon ; > > wanghuiqiang ; Guohanjun (Hanjun Guo) > > ; Steven Price ; Sami > > Mujawar ; Eric Auger ; > > yangyicong > > Subject: Re: [PATCH v7 2/9] ACPI/IORT: Add support for RMR node parsing > > > [...] > > > > > > > > > On the prot value assignment based on the remapping flag, I'd like > > > > to hear Robin/Joerg's opinion, I'd avoid being in a situation where > > > > "normally" this would work but then we have to quirk it. > > > > > > > > Is this a valid assumption _always_ ? > > > > > > No. Certainly applying IOMMU_CACHE without reference to the device's > > > _CCA attribute or how CPUs may be accessing a shared buffer could lead > > > to a loss of coherency. At worst, applying IOMMU_MMIO to a > > > device-private buffer *could* cause the device to lose coherency with > > > itself if the memory underlying the RMR may have allocated into system > > > caches. Note that the expected use for non-remappable RMRs is the > > > device holding some sort of long-lived private data in system RAM - > > > the MSI doorbell trick is far more of a niche hack really. > > > > > > At the very least I think we need to refer to the device's memory > > > access properties here. > > > > > > Jon, Laurentiu - how do RMRs correspond to the EFI memory map on your > > > firmware? I'm starting to think that as long as the underlying memory > > > is described appropriately there then we should be able to infer > > > correct attributes from the EFI memory type and flags. > > > > The devices are all cache coherent and marked as _CCA, 1. The Memory > > regions are in the virt table as ARM_MEMORY_REGION_ATTRIBUTE_DEVICE. > > > > The current chicken and egg problem we have is that during the fsl-mc-bus > > initialization we call > > > > error = acpi_dma_configure_id(&pdev->dev, DEV_DMA_COHERENT, > > &mc_stream_id); > > > > which gets deferred because the SMMU has not been initialized yet. Then we > > initialize the RMR tables but there is no device reference there to be able to > > query device properties, only the stream id. After the IORT tables are parsed > > and the SMMU is setup, on the second device probe we associate everything > > based on the stream id and the fsl-mc-bus device is able to claim its 1-1 DMA > > mappings. > > Can we solve this order problem by delaying the iommu_alloc_resv_region() > to the iommu_dma_get_rmr_resv_regions(dev, list) ? We could invoke > device_get_dma_attr() from there which I believe will return the _CCA attribute. > > Or is that still early to invoke that? That looks like it should work. Do we then also need to parse through the VirtualMemoryTable matching the start and end addresses to determine the other memory attributes like MMIO? -Jon > > Thanks, > Shameer > > > cat /sys/kernel/iommu_groups/0/reserved_regions > > 0x0000000001000000 0x0000000010ffffff direct-relaxable > > 0x0000000008000000 0x00000000080fffff msi > > 0x000000080c000000 0x000000081bffffff direct-relaxable > > 0x0000001c00000000 0x0000001c001fffff direct-relaxable > > 0x0000002080000000 0x000000209fffffff direct-relaxable > > > > -Jon > > > > > > > > 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 X-Spam-Level: X-Spam-Status: No, score=-3.5 required=3.0 tests=BAYES_00,DKIM_INVALID, DKIM_SIGNED,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id F193CC433FE for ; Thu, 16 Sep 2021 07:52:52 +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 9D05F610A4 for ; Thu, 16 Sep 2021 07:52:52 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 9D05F610A4 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=solid-run.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 60032400E6; Thu, 16 Sep 2021 07:52:52 +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 M7HC4DyZDZG4; Thu, 16 Sep 2021 07:52:51 +0000 (UTC) Received: from lists.linuxfoundation.org (lf-lists.osuosl.org [140.211.9.56]) by smtp2.osuosl.org (Postfix) with ESMTPS id E4159401A0; Thu, 16 Sep 2021 07:52:50 +0000 (UTC) Received: from lf-lists.osuosl.org (localhost [127.0.0.1]) by lists.linuxfoundation.org (Postfix) with ESMTP id B1C1CC000F; Thu, 16 Sep 2021 07:52:50 +0000 (UTC) Received: from smtp4.osuosl.org (smtp4.osuosl.org [IPv6:2605:bc80:3010::137]) by lists.linuxfoundation.org (Postfix) with ESMTP id 022ECC000D for ; Thu, 16 Sep 2021 07:52:49 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp4.osuosl.org (Postfix) with ESMTP id D6AE6404D0 for ; Thu, 16 Sep 2021 07:52:48 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org Authentication-Results: smtp4.osuosl.org (amavisd-new); dkim=pass (2048-bit key) header.d=solid-run-com.20150623.gappssmtp.com 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 CYniV1i4D07w for ; Thu, 16 Sep 2021 07:52:48 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.8.0 Received: from mail-ed1-x530.google.com (mail-ed1-x530.google.com [IPv6:2a00:1450:4864:20::530]) by smtp4.osuosl.org (Postfix) with ESMTPS id D608A404C7 for ; Thu, 16 Sep 2021 07:52:47 +0000 (UTC) Received: by mail-ed1-x530.google.com with SMTP id g8so13435841edt.7 for ; Thu, 16 Sep 2021 00:52:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=solid-run-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=ODMKOAGqD4ItUpYtqxdJhUq4QAGfb72lqYAxg7uVUGE=; b=chtAbpIChinWBdEU1gL0ntvM9+0WUqRdjW5xXbWXxve4i322V8dGlTe9RiiuK3Ky4X c4akEZ5ZtlGIE4Oq5bKagynGKAzDDWLhPD16IaRA87RHwvszd2Dd9BcUfbSoGsR9eW23 jCna1ptofFWrFzh1WoFFdzasf5ZaWs3oaf2rCLIudjsKhBAEHN4skc61+FZLbHn63DN0 rNGf+UyI8WD/28M5HK/XKfP5ioyaoiYkqVrB9g+dtXaUnXSgWMUJPcNDt4JNfSsTxCBj blBr5Gzj1Bep+7R7sSd1nskzkOQz0mQNLiq9MFxbbycGsJJRkg9ZK3NBERnWlMz9RRRQ voAg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=ODMKOAGqD4ItUpYtqxdJhUq4QAGfb72lqYAxg7uVUGE=; b=gigf5pUhYkkdPRXPfHNzg2nS3wW//qfexFlebJuVdB3sI/r7soC8te9KNJ6468gsXY tKB8kPjajxgQsl76hMMlAUHLXiif/JaBGlf/recLCvGohsKSykTHA/FxU6pjatQ9Qk14 /3v7mqzPxY9AV9/PiH0TFRfI8ID+A9DyQu/7hLhwaXSuQ94UApnMAdcwM70OUmo+5z2O 88jl0lmLWJn4mwbQiD6s+DPaqbukagXRrjHwv9jAaP9vkKyoCb0nL+lIX+oa8wuT9E6P PnNlZJG+krrt4483GSJfXvxQA6p1i+++VtsbL2JHnkcd4xfhuY8qQx7Mblu5Qc5Obkwd WGRQ== X-Gm-Message-State: AOAM530gxhyNnO1+pG4+LOB2HBxYT6d/P9aDqv8UuNbxxdkjp95XzWxd sg1nUtArImUbkuph1lj8mc6qfsLHy7FqiLm7y3ZLpA== X-Google-Smtp-Source: ABdhPJyKDvyZKYCRYuxgjitZgDg2r13roWQBKzWOY1Mt3prlNydzDybS+gDSrHtYZ6S21wAVeWfjewN4V0nE2cFjwQw= X-Received: by 2002:a17:906:1341:: with SMTP id x1mr4645297ejb.277.1631778765895; Thu, 16 Sep 2021 00:52:45 -0700 (PDT) MIME-Version: 1.0 References: <20210805080724.480-1-shameerali.kolothum.thodi@huawei.com> <20210805080724.480-3-shameerali.kolothum.thodi@huawei.com> <20210805160319.GB23085@lpieralisi> <5d9bebdf-6eb5-49a0-2e8f-490df2d6754d@arm.com> In-Reply-To: From: Jon Nettleton Date: Thu, 16 Sep 2021 09:52:08 +0200 Message-ID: Subject: Re: [PATCH v7 2/9] ACPI/IORT: Add support for RMR node parsing To: Shameerali Kolothum Thodi Cc: Will Deacon , Steven Price , ACPI Devel Maling List , Linux IOMMU , wanghuiqiang , "Guohanjun \(Hanjun Guo\)" , yangyicong , Sami Mujawar , Robin Murphy , 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-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: iommu-bounces@lists.linux-foundation.org Sender: "iommu" On Thu, Sep 16, 2021 at 9:26 AM Shameerali Kolothum Thodi wrote: > > > > > -----Original Message----- > > From: Jon Nettleton [mailto:jon@solid-run.com] > > Sent: 06 September 2021 20:51 > > To: Robin Murphy > > Cc: Lorenzo Pieralisi ; Shameerali Kolothum Thodi > > ; Laurentiu Tudor > > ; linux-arm-kernel > > ; ACPI Devel Maling List > > ; Linux IOMMU > > ; Linuxarm ; > > Joerg Roedel ; Will Deacon ; > > wanghuiqiang ; Guohanjun (Hanjun Guo) > > ; Steven Price ; Sami > > Mujawar ; Eric Auger ; > > yangyicong > > Subject: Re: [PATCH v7 2/9] ACPI/IORT: Add support for RMR node parsing > > > [...] > > > > > > > > > On the prot value assignment based on the remapping flag, I'd like > > > > to hear Robin/Joerg's opinion, I'd avoid being in a situation where > > > > "normally" this would work but then we have to quirk it. > > > > > > > > Is this a valid assumption _always_ ? > > > > > > No. Certainly applying IOMMU_CACHE without reference to the device's > > > _CCA attribute or how CPUs may be accessing a shared buffer could lead > > > to a loss of coherency. At worst, applying IOMMU_MMIO to a > > > device-private buffer *could* cause the device to lose coherency with > > > itself if the memory underlying the RMR may have allocated into system > > > caches. Note that the expected use for non-remappable RMRs is the > > > device holding some sort of long-lived private data in system RAM - > > > the MSI doorbell trick is far more of a niche hack really. > > > > > > At the very least I think we need to refer to the device's memory > > > access properties here. > > > > > > Jon, Laurentiu - how do RMRs correspond to the EFI memory map on your > > > firmware? I'm starting to think that as long as the underlying memory > > > is described appropriately there then we should be able to infer > > > correct attributes from the EFI memory type and flags. > > > > The devices are all cache coherent and marked as _CCA, 1. The Memory > > regions are in the virt table as ARM_MEMORY_REGION_ATTRIBUTE_DEVICE. > > > > The current chicken and egg problem we have is that during the fsl-mc-bus > > initialization we call > > > > error = acpi_dma_configure_id(&pdev->dev, DEV_DMA_COHERENT, > > &mc_stream_id); > > > > which gets deferred because the SMMU has not been initialized yet. Then we > > initialize the RMR tables but there is no device reference there to be able to > > query device properties, only the stream id. After the IORT tables are parsed > > and the SMMU is setup, on the second device probe we associate everything > > based on the stream id and the fsl-mc-bus device is able to claim its 1-1 DMA > > mappings. > > Can we solve this order problem by delaying the iommu_alloc_resv_region() > to the iommu_dma_get_rmr_resv_regions(dev, list) ? We could invoke > device_get_dma_attr() from there which I believe will return the _CCA attribute. > > Or is that still early to invoke that? That looks like it should work. Do we then also need to parse through the VirtualMemoryTable matching the start and end addresses to determine the other memory attributes like MMIO? -Jon > > Thanks, > Shameer > > > cat /sys/kernel/iommu_groups/0/reserved_regions > > 0x0000000001000000 0x0000000010ffffff direct-relaxable > > 0x0000000008000000 0x00000000080fffff msi > > 0x000000080c000000 0x000000081bffffff direct-relaxable > > 0x0000001c00000000 0x0000001c001fffff direct-relaxable > > 0x0000002080000000 0x000000209fffffff direct-relaxable > > > > -Jon > > > > > > > > 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 X-Spam-Level: X-Spam-Status: No, score=-4.1 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id B51B4C433EF for ; Thu, 16 Sep 2021 07:54:48 +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 7C310611CA for ; Thu, 16 Sep 2021 07:54:48 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 7C310611CA Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=solid-run.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-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:Cc:To:Subject:Message-ID:Date:From: In-Reply-To:References:MIME-Version:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=FfZmupCkjALZB3F9WhcmzrxKO5udbr0GDvssTr4PJaI=; b=onW+UjzkzzYVeg V2Lddkqaj6l4n3QPlRRwRPGn5NEcMRA9ITzHUF1ns4gduyUd96BicUhw0F0HHjQq5I+yAkpUUXUOW Qkt9Xs9OA7AtcpO1NrwHg7lMdz8PVY0CWca5/O+NNOYP/umfVunTJde9enQ9Xsk6aEkXsJP+dEUba o36/vH9MZiwTQEiX8BgHCKWDFxzrbtQhKE9IgfyHslayzF2FxniIe7W20NEVbMMxgqU5FAHZBox0C njQ1C3hCoscwzfOPsQcRVlDV0RLjoYBe/9Ck6nyBJtWijo/qu6NX3+k2NAOwDgaBKwHQ41LrGduye wq9+kw+ETN3gGGABjXwg==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1mQmCU-00AVb6-1O; Thu, 16 Sep 2021 07:52:54 +0000 Received: from mail-ed1-x52a.google.com ([2a00:1450:4864:20::52a]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1mQmCQ-00AVaL-9G for linux-arm-kernel@lists.infradead.org; Thu, 16 Sep 2021 07:52:51 +0000 Received: by mail-ed1-x52a.google.com with SMTP id v24so13425914eda.3 for ; Thu, 16 Sep 2021 00:52:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=solid-run-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=ODMKOAGqD4ItUpYtqxdJhUq4QAGfb72lqYAxg7uVUGE=; b=chtAbpIChinWBdEU1gL0ntvM9+0WUqRdjW5xXbWXxve4i322V8dGlTe9RiiuK3Ky4X c4akEZ5ZtlGIE4Oq5bKagynGKAzDDWLhPD16IaRA87RHwvszd2Dd9BcUfbSoGsR9eW23 jCna1ptofFWrFzh1WoFFdzasf5ZaWs3oaf2rCLIudjsKhBAEHN4skc61+FZLbHn63DN0 rNGf+UyI8WD/28M5HK/XKfP5ioyaoiYkqVrB9g+dtXaUnXSgWMUJPcNDt4JNfSsTxCBj blBr5Gzj1Bep+7R7sSd1nskzkOQz0mQNLiq9MFxbbycGsJJRkg9ZK3NBERnWlMz9RRRQ voAg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=ODMKOAGqD4ItUpYtqxdJhUq4QAGfb72lqYAxg7uVUGE=; b=TvPBDV1HT3gA6o/ex78bTa3gzvr/FeHyEE/c2TgumZvyikaOlN3SjaoDWnavjhCaGd al/lYPaXy7EwfBUBCBGAmEYBXKnKA1pfQzw1i9Bnwd3P1X2QbNBSVzwoJBhEgTsSPQBo PxDfJigvDCKK/DcKc6nZg62bBVBG1IcReeXkJZqhSzhhhQo40if6MBy1W/mq2Wt9NxHD dcJnDhaw3P+pu2iSzyppakezcOroZ+yvB3a+JvBJkRCk8CwL29coi+vmV8ZVSGq7ENil JvmrF95tspbiMdng40iig1XfAaaHz7SSm8qAiYf/sxr3WXVcPfZ1a3Bxyl48L4sZT34F ekXA== X-Gm-Message-State: AOAM532bSeqDiSlF40QL/agbO6NLvH5iSvBu9rAx/ltv4rE9Jxmo7V/H bT2HGIPBAWAGMLJ25KgdqnqG05LP9c02MoMuPf4jag== X-Google-Smtp-Source: ABdhPJyKDvyZKYCRYuxgjitZgDg2r13roWQBKzWOY1Mt3prlNydzDybS+gDSrHtYZ6S21wAVeWfjewN4V0nE2cFjwQw= X-Received: by 2002:a17:906:1341:: with SMTP id x1mr4645297ejb.277.1631778765895; Thu, 16 Sep 2021 00:52:45 -0700 (PDT) MIME-Version: 1.0 References: <20210805080724.480-1-shameerali.kolothum.thodi@huawei.com> <20210805080724.480-3-shameerali.kolothum.thodi@huawei.com> <20210805160319.GB23085@lpieralisi> <5d9bebdf-6eb5-49a0-2e8f-490df2d6754d@arm.com> In-Reply-To: From: Jon Nettleton Date: Thu, 16 Sep 2021 09:52:08 +0200 Message-ID: Subject: Re: [PATCH v7 2/9] ACPI/IORT: Add support for RMR node parsing To: Shameerali Kolothum Thodi Cc: Robin Murphy , Lorenzo Pieralisi , Laurentiu Tudor , linux-arm-kernel , ACPI Devel Maling List , Linux IOMMU , Joerg Roedel , Will Deacon , wanghuiqiang , "Guohanjun (Hanjun Guo)" , Steven Price , Sami Mujawar , Eric Auger , yangyicong X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20210916_005250_424876_061C00BA X-CRM114-Status: GOOD ( 34.33 ) 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-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Thu, Sep 16, 2021 at 9:26 AM Shameerali Kolothum Thodi wrote: > > > > > -----Original Message----- > > From: Jon Nettleton [mailto:jon@solid-run.com] > > Sent: 06 September 2021 20:51 > > To: Robin Murphy > > Cc: Lorenzo Pieralisi ; Shameerali Kolothum Thodi > > ; Laurentiu Tudor > > ; linux-arm-kernel > > ; ACPI Devel Maling List > > ; Linux IOMMU > > ; Linuxarm ; > > Joerg Roedel ; Will Deacon ; > > wanghuiqiang ; Guohanjun (Hanjun Guo) > > ; Steven Price ; Sami > > Mujawar ; Eric Auger ; > > yangyicong > > Subject: Re: [PATCH v7 2/9] ACPI/IORT: Add support for RMR node parsing > > > [...] > > > > > > > > > On the prot value assignment based on the remapping flag, I'd like > > > > to hear Robin/Joerg's opinion, I'd avoid being in a situation where > > > > "normally" this would work but then we have to quirk it. > > > > > > > > Is this a valid assumption _always_ ? > > > > > > No. Certainly applying IOMMU_CACHE without reference to the device's > > > _CCA attribute or how CPUs may be accessing a shared buffer could lead > > > to a loss of coherency. At worst, applying IOMMU_MMIO to a > > > device-private buffer *could* cause the device to lose coherency with > > > itself if the memory underlying the RMR may have allocated into system > > > caches. Note that the expected use for non-remappable RMRs is the > > > device holding some sort of long-lived private data in system RAM - > > > the MSI doorbell trick is far more of a niche hack really. > > > > > > At the very least I think we need to refer to the device's memory > > > access properties here. > > > > > > Jon, Laurentiu - how do RMRs correspond to the EFI memory map on your > > > firmware? I'm starting to think that as long as the underlying memory > > > is described appropriately there then we should be able to infer > > > correct attributes from the EFI memory type and flags. > > > > The devices are all cache coherent and marked as _CCA, 1. The Memory > > regions are in the virt table as ARM_MEMORY_REGION_ATTRIBUTE_DEVICE. > > > > The current chicken and egg problem we have is that during the fsl-mc-bus > > initialization we call > > > > error = acpi_dma_configure_id(&pdev->dev, DEV_DMA_COHERENT, > > &mc_stream_id); > > > > which gets deferred because the SMMU has not been initialized yet. Then we > > initialize the RMR tables but there is no device reference there to be able to > > query device properties, only the stream id. After the IORT tables are parsed > > and the SMMU is setup, on the second device probe we associate everything > > based on the stream id and the fsl-mc-bus device is able to claim its 1-1 DMA > > mappings. > > Can we solve this order problem by delaying the iommu_alloc_resv_region() > to the iommu_dma_get_rmr_resv_regions(dev, list) ? We could invoke > device_get_dma_attr() from there which I believe will return the _CCA attribute. > > Or is that still early to invoke that? That looks like it should work. Do we then also need to parse through the VirtualMemoryTable matching the start and end addresses to determine the other memory attributes like MMIO? -Jon > > Thanks, > Shameer > > > cat /sys/kernel/iommu_groups/0/reserved_regions > > 0x0000000001000000 0x0000000010ffffff direct-relaxable > > 0x0000000008000000 0x00000000080fffff msi > > 0x000000080c000000 0x000000081bffffff direct-relaxable > > 0x0000001c00000000 0x0000001c001fffff direct-relaxable > > 0x0000002080000000 0x000000209fffffff direct-relaxable > > > > -Jon > > > > > > > > Robin. _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel