All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andy Shevchenko <andy.shevchenko@gmail.com>
To: Claire Chang <tientzu@chromium.org>
Cc: Rob Herring <robh+dt@kernel.org>,
	Michael Ellerman <mpe@ellerman.id.au>,
	Joerg Roedel <joro@8bytes.org>, Will Deacon <will@kernel.org>,
	Frank Rowand <frowand.list@gmail.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Boris Ostrovsky <boris.ostrovsky@oracle.com>,
	Juergen Gross <jgross@suse.com>, Christoph Hellwig <hch@lst.de>,
	Marek Szyprowski <m.szyprowski@samsung.com>,
	benh@kernel.crashing.org, paulus@samba.org,
	"list@263.net:IOMMU DRIVERS" <iommu@lists.linux-foundation.org>,
	sstabellini@kernel.org, Robin Murphy <robin.murphy@arm.com>,
	grant.likely@arm.com, xypron.glpk@gmx.de,
	Thierry Reding <treding@nvidia.com>,
	mingo@kernel.org, bauerman@linux.ibm.com, peterz@infradead.org,
	Greg KH <gregkh@linuxfoundation.org>,
	Saravana Kannan <saravanak@google.com>,
	"Rafael J . Wysocki" <rafael.j.wysocki@intel.com>,
	heikki.krogerus@linux.intel.com,
	Andy Shevchenko <andriy.shevchenko@linux.intel.com>,
	Randy Dunlap <rdunlap@infradead.org>,
	Dan Williams <dan.j.williams@intel.com>,
	Bartosz Golaszewski <bgolaszewski@baylibre.com>,
	linux-devicetree <devicetree@vger.kernel.org>,
	lkml <linux-kernel@vger.kernel.org>,
	linuxppc-dev@lists.ozlabs.org, xen-devel@lists.xenproject.org,
	Nicolas Boichat <drinkcat@chromium.org>,
	Jim Quinlan <james.quinlan@broadcom.com>,
	tfiga@chromium.org, bskeggs@redhat.com, bhelgaas@google.com,
	chris@chris-wilson.co.uk, daniel@ffwll.ch, airlied@linux.ie,
	dri-devel@lists.freedesktop.org, intel-gfx@lists.freedesktop.org,
	jani.nikula@linux.intel.com, jxgao@google.com,
	joonas.lahtinen@linux.intel.com, linux-pci@vger.kernel.org,
	maarten.lankhorst@linux.intel.com, matthew.auld@intel.com,
	rodrigo.vivi@intel.com, thomas.hellstrom@linux.intel.com,
	thomas.lendacky@amd.com, quic_qiancai@quicinc.com
Subject: Re: [PATCH v15 10/12] swiotlb: Add restricted DMA pool initialization
Date: Fri, 27 Aug 2021 09:58:32 +0300	[thread overview]
Message-ID: <CAHp75VfVhVGFEQGeUKajrUKmkx_et_KakDDgroC2BrMMhd62yg@mail.gmail.com> (raw)
In-Reply-To: <20210624155526.2775863-11-tientzu@chromium.org>

On Thu, Jun 24, 2021 at 6:59 PM Claire Chang <tientzu@chromium.org> wrote:
>
> Add the initialization function to create restricted DMA pools from
> matching reserved-memory nodes.
>
> Regardless of swiotlb setting, the restricted DMA pool is preferred if
> available.
>
> The restricted DMA pools provide a basic level of protection against the
> DMA overwriting buffer contents at unexpected times. However, to protect
> against general data leakage and system memory corruption, the system
> needs to provide a way to lock down the memory access, e.g., MPU.





> +static int rmem_swiotlb_device_init(struct reserved_mem *rmem,
> +                                   struct device *dev)
> +{
> +       struct io_tlb_mem *mem = rmem->priv;
> +       unsigned long nslabs = rmem->size >> IO_TLB_SHIFT;
> +
> +       /*
> +        * Since multiple devices can share the same pool, the private data,
> +        * io_tlb_mem struct, will be initialized by the first device attached
> +        * to it.
> +        */

> +       if (!mem) {

Can it be rather

if (mem)
  goto out_assign;

or so?

> +               mem = kzalloc(struct_size(mem, slots, nslabs), GFP_KERNEL);
> +               if (!mem)
> +                       return -ENOMEM;
> +
> +               set_memory_decrypted((unsigned long)phys_to_virt(rmem->base),
> +                                    rmem->size >> PAGE_SHIFT);

Below you are using a macro from pfn.h, but not here, I think it's PFN_DOWN().

> +               swiotlb_init_io_tlb_mem(mem, rmem->base, nslabs, false);
> +               mem->force_bounce = true;
> +               mem->for_alloc = true;
> +
> +               rmem->priv = mem;
> +
> +               if (IS_ENABLED(CONFIG_DEBUG_FS)) {
> +                       mem->debugfs =
> +                               debugfs_create_dir(rmem->name, debugfs_dir);
> +                       swiotlb_create_debugfs_files(mem);
> +               }
> +       }
> +
> +       dev->dma_io_tlb_mem = mem;
> +
> +       return 0;
> +}
> +
> +static void rmem_swiotlb_device_release(struct reserved_mem *rmem,
> +                                       struct device *dev)
> +{
> +       dev->dma_io_tlb_mem = io_tlb_default_mem;
> +}
> +
> +static const struct reserved_mem_ops rmem_swiotlb_ops = {
> +       .device_init = rmem_swiotlb_device_init,
> +       .device_release = rmem_swiotlb_device_release,
> +};
> +
> +static int __init rmem_swiotlb_setup(struct reserved_mem *rmem)
> +{
> +       unsigned long node = rmem->fdt_node;
> +
> +       if (of_get_flat_dt_prop(node, "reusable", NULL) ||
> +           of_get_flat_dt_prop(node, "linux,cma-default", NULL) ||
> +           of_get_flat_dt_prop(node, "linux,dma-default", NULL) ||
> +           of_get_flat_dt_prop(node, "no-map", NULL))
> +               return -EINVAL;
> +
> +       if (PageHighMem(pfn_to_page(PHYS_PFN(rmem->base)))) {
> +               pr_err("Restricted DMA pool must be accessible within the linear mapping.");
> +               return -EINVAL;
> +       }
> +
> +       rmem->ops = &rmem_swiotlb_ops;
> +       pr_info("Reserved memory: created restricted DMA pool at %pa, size %ld MiB\n",
> +               &rmem->base, (unsigned long)rmem->size / SZ_1M);

Oh là là, besides explicit casting that I believe can be avoided, %ld
!= unsigned long. Can you check the printk-formats.rst document?

> +       return 0;
> +}
> +
> +RESERVEDMEM_OF_DECLARE(dma, "restricted-dma-pool", rmem_swiotlb_setup);
>  #endif /* CONFIG_DMA_RESTRICTED_POOL */

-- 
With Best Regards,
Andy Shevchenko

WARNING: multiple messages have this Message-ID (diff)
From: Andy Shevchenko <andy.shevchenko@gmail.com>
To: Claire Chang <tientzu@chromium.org>
Cc: heikki.krogerus@linux.intel.com,
	thomas.hellstrom@linux.intel.com, peterz@infradead.org,
	benh@kernel.crashing.org, joonas.lahtinen@linux.intel.com,
	dri-devel@lists.freedesktop.org, chris@chris-wilson.co.uk,
	grant.likely@arm.com, paulus@samba.org,
	Frank Rowand <frowand.list@gmail.com>,
	mingo@kernel.org, sstabellini@kernel.org,
	Saravana Kannan <saravanak@google.com>,
	Michael Ellerman <mpe@ellerman.id.au>,
	"Rafael J . Wysocki" <rafael.j.wysocki@intel.com>,
	Christoph Hellwig <hch@lst.de>,
	Bartosz Golaszewski <bgolaszewski@baylibre.com>,
	bskeggs@redhat.com, linux-pci@vger.kernel.org,
	xen-devel@lists.xenproject.org,
	Thierry Reding <treding@nvidia.com>,
	intel-gfx@lists.freedesktop.org, matthew.auld@intel.com,
	linux-devicetree <devicetree@vger.kernel.org>,
	jxgao@google.com, daniel@ffwll.ch, Will Deacon <will@kernel.org>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	maarten.lankhorst@linux.intel.com, airlied@linux.ie,
	Dan Williams <dan.j.williams@intel.com>,
	linuxppc-dev@lists.ozlabs.org, jani.nikula@linux.intel.com,
	Rob Herring <robh+dt@kernel.org>,
	rodrigo.vivi@intel.com, bhelgaas@google.com,
	Boris Ostrovsky <boris.ostrovsky@oracle.com>,
	Andy Shevchenko <andriy.shevchenko@linux.intel.com>,
	Juergen Gross <jgross@suse.com>,
	Nicolas Boichat <drinkcat@chromium.org>,
	Greg KH <gregkh@linuxfoundation.org>,
	Randy Dunlap <rdunlap@infradead.org>,
	quic_qiancai@quicinc.com, lkml <linux-kernel@vger.kernel.org>,
	"list@263.net:IOMMU DRIVERS" <iommu@lists.linux-foundation.org>,
	Jim Quinlan <james.quinlan@broadcom.com>,
	xypron.glpk@gmx.de, thomas.lendacky@amd.com,
	Robin Murphy <robin.murphy@arm.com>,
	bauerman@linux.ibm.com
Subject: Re: [PATCH v15 10/12] swiotlb: Add restricted DMA pool initialization
Date: Fri, 27 Aug 2021 09:58:32 +0300	[thread overview]
Message-ID: <CAHp75VfVhVGFEQGeUKajrUKmkx_et_KakDDgroC2BrMMhd62yg@mail.gmail.com> (raw)
In-Reply-To: <20210624155526.2775863-11-tientzu@chromium.org>

On Thu, Jun 24, 2021 at 6:59 PM Claire Chang <tientzu@chromium.org> wrote:
>
> Add the initialization function to create restricted DMA pools from
> matching reserved-memory nodes.
>
> Regardless of swiotlb setting, the restricted DMA pool is preferred if
> available.
>
> The restricted DMA pools provide a basic level of protection against the
> DMA overwriting buffer contents at unexpected times. However, to protect
> against general data leakage and system memory corruption, the system
> needs to provide a way to lock down the memory access, e.g., MPU.





> +static int rmem_swiotlb_device_init(struct reserved_mem *rmem,
> +                                   struct device *dev)
> +{
> +       struct io_tlb_mem *mem = rmem->priv;
> +       unsigned long nslabs = rmem->size >> IO_TLB_SHIFT;
> +
> +       /*
> +        * Since multiple devices can share the same pool, the private data,
> +        * io_tlb_mem struct, will be initialized by the first device attached
> +        * to it.
> +        */

> +       if (!mem) {

Can it be rather

if (mem)
  goto out_assign;

or so?

> +               mem = kzalloc(struct_size(mem, slots, nslabs), GFP_KERNEL);
> +               if (!mem)
> +                       return -ENOMEM;
> +
> +               set_memory_decrypted((unsigned long)phys_to_virt(rmem->base),
> +                                    rmem->size >> PAGE_SHIFT);

Below you are using a macro from pfn.h, but not here, I think it's PFN_DOWN().

> +               swiotlb_init_io_tlb_mem(mem, rmem->base, nslabs, false);
> +               mem->force_bounce = true;
> +               mem->for_alloc = true;
> +
> +               rmem->priv = mem;
> +
> +               if (IS_ENABLED(CONFIG_DEBUG_FS)) {
> +                       mem->debugfs =
> +                               debugfs_create_dir(rmem->name, debugfs_dir);
> +                       swiotlb_create_debugfs_files(mem);
> +               }
> +       }
> +
> +       dev->dma_io_tlb_mem = mem;
> +
> +       return 0;
> +}
> +
> +static void rmem_swiotlb_device_release(struct reserved_mem *rmem,
> +                                       struct device *dev)
> +{
> +       dev->dma_io_tlb_mem = io_tlb_default_mem;
> +}
> +
> +static const struct reserved_mem_ops rmem_swiotlb_ops = {
> +       .device_init = rmem_swiotlb_device_init,
> +       .device_release = rmem_swiotlb_device_release,
> +};
> +
> +static int __init rmem_swiotlb_setup(struct reserved_mem *rmem)
> +{
> +       unsigned long node = rmem->fdt_node;
> +
> +       if (of_get_flat_dt_prop(node, "reusable", NULL) ||
> +           of_get_flat_dt_prop(node, "linux,cma-default", NULL) ||
> +           of_get_flat_dt_prop(node, "linux,dma-default", NULL) ||
> +           of_get_flat_dt_prop(node, "no-map", NULL))
> +               return -EINVAL;
> +
> +       if (PageHighMem(pfn_to_page(PHYS_PFN(rmem->base)))) {
> +               pr_err("Restricted DMA pool must be accessible within the linear mapping.");
> +               return -EINVAL;
> +       }
> +
> +       rmem->ops = &rmem_swiotlb_ops;
> +       pr_info("Reserved memory: created restricted DMA pool at %pa, size %ld MiB\n",
> +               &rmem->base, (unsigned long)rmem->size / SZ_1M);

Oh là là, besides explicit casting that I believe can be avoided, %ld
!= unsigned long. Can you check the printk-formats.rst document?

> +       return 0;
> +}
> +
> +RESERVEDMEM_OF_DECLARE(dma, "restricted-dma-pool", rmem_swiotlb_setup);
>  #endif /* CONFIG_DMA_RESTRICTED_POOL */

-- 
With Best Regards,
Andy Shevchenko
_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu

WARNING: multiple messages have this Message-ID (diff)
From: Andy Shevchenko <andy.shevchenko@gmail.com>
To: Claire Chang <tientzu@chromium.org>
Cc: Rob Herring <robh+dt@kernel.org>,
	Michael Ellerman <mpe@ellerman.id.au>,
	 Joerg Roedel <joro@8bytes.org>, Will Deacon <will@kernel.org>,
	Frank Rowand <frowand.list@gmail.com>,
	 Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Boris Ostrovsky <boris.ostrovsky@oracle.com>,
	 Juergen Gross <jgross@suse.com>, Christoph Hellwig <hch@lst.de>,
	 Marek Szyprowski <m.szyprowski@samsung.com>,
	benh@kernel.crashing.org, paulus@samba.org,
	 "list@263.net:IOMMU DRIVERS" <iommu@lists.linux-foundation.org>,
	sstabellini@kernel.org,  Robin Murphy <robin.murphy@arm.com>,
	grant.likely@arm.com, xypron.glpk@gmx.de,
	 Thierry Reding <treding@nvidia.com>,
	mingo@kernel.org, bauerman@linux.ibm.com,  peterz@infradead.org,
	Greg KH <gregkh@linuxfoundation.org>,
	 Saravana Kannan <saravanak@google.com>,
	"Rafael J . Wysocki" <rafael.j.wysocki@intel.com>,
	 heikki.krogerus@linux.intel.com,
	 Andy Shevchenko <andriy.shevchenko@linux.intel.com>,
	Randy Dunlap <rdunlap@infradead.org>,
	 Dan Williams <dan.j.williams@intel.com>,
	Bartosz Golaszewski <bgolaszewski@baylibre.com>,
	 linux-devicetree <devicetree@vger.kernel.org>,
	lkml <linux-kernel@vger.kernel.org>,
	 linuxppc-dev@lists.ozlabs.org, xen-devel@lists.xenproject.org,
	 Nicolas Boichat <drinkcat@chromium.org>,
	Jim Quinlan <james.quinlan@broadcom.com>,
	tfiga@chromium.org,  bskeggs@redhat.com, bhelgaas@google.com,
	chris@chris-wilson.co.uk,  daniel@ffwll.ch, airlied@linux.ie,
	dri-devel@lists.freedesktop.org,
	 intel-gfx@lists.freedesktop.org, jani.nikula@linux.intel.com,
	 jxgao@google.com, joonas.lahtinen@linux.intel.com,
	linux-pci@vger.kernel.org,  maarten.lankhorst@linux.intel.com,
	matthew.auld@intel.com,  rodrigo.vivi@intel.com,
	thomas.hellstrom@linux.intel.com,  thomas.lendacky@amd.com,
	quic_qiancai@quicinc.com
Subject: Re: [Intel-gfx] [PATCH v15 10/12] swiotlb: Add restricted DMA pool initialization
Date: Fri, 27 Aug 2021 09:58:32 +0300	[thread overview]
Message-ID: <CAHp75VfVhVGFEQGeUKajrUKmkx_et_KakDDgroC2BrMMhd62yg@mail.gmail.com> (raw)
In-Reply-To: <20210624155526.2775863-11-tientzu@chromium.org>

On Thu, Jun 24, 2021 at 6:59 PM Claire Chang <tientzu@chromium.org> wrote:
>
> Add the initialization function to create restricted DMA pools from
> matching reserved-memory nodes.
>
> Regardless of swiotlb setting, the restricted DMA pool is preferred if
> available.
>
> The restricted DMA pools provide a basic level of protection against the
> DMA overwriting buffer contents at unexpected times. However, to protect
> against general data leakage and system memory corruption, the system
> needs to provide a way to lock down the memory access, e.g., MPU.





> +static int rmem_swiotlb_device_init(struct reserved_mem *rmem,
> +                                   struct device *dev)
> +{
> +       struct io_tlb_mem *mem = rmem->priv;
> +       unsigned long nslabs = rmem->size >> IO_TLB_SHIFT;
> +
> +       /*
> +        * Since multiple devices can share the same pool, the private data,
> +        * io_tlb_mem struct, will be initialized by the first device attached
> +        * to it.
> +        */

> +       if (!mem) {

Can it be rather

if (mem)
  goto out_assign;

or so?

> +               mem = kzalloc(struct_size(mem, slots, nslabs), GFP_KERNEL);
> +               if (!mem)
> +                       return -ENOMEM;
> +
> +               set_memory_decrypted((unsigned long)phys_to_virt(rmem->base),
> +                                    rmem->size >> PAGE_SHIFT);

Below you are using a macro from pfn.h, but not here, I think it's PFN_DOWN().

> +               swiotlb_init_io_tlb_mem(mem, rmem->base, nslabs, false);
> +               mem->force_bounce = true;
> +               mem->for_alloc = true;
> +
> +               rmem->priv = mem;
> +
> +               if (IS_ENABLED(CONFIG_DEBUG_FS)) {
> +                       mem->debugfs =
> +                               debugfs_create_dir(rmem->name, debugfs_dir);
> +                       swiotlb_create_debugfs_files(mem);
> +               }
> +       }
> +
> +       dev->dma_io_tlb_mem = mem;
> +
> +       return 0;
> +}
> +
> +static void rmem_swiotlb_device_release(struct reserved_mem *rmem,
> +                                       struct device *dev)
> +{
> +       dev->dma_io_tlb_mem = io_tlb_default_mem;
> +}
> +
> +static const struct reserved_mem_ops rmem_swiotlb_ops = {
> +       .device_init = rmem_swiotlb_device_init,
> +       .device_release = rmem_swiotlb_device_release,
> +};
> +
> +static int __init rmem_swiotlb_setup(struct reserved_mem *rmem)
> +{
> +       unsigned long node = rmem->fdt_node;
> +
> +       if (of_get_flat_dt_prop(node, "reusable", NULL) ||
> +           of_get_flat_dt_prop(node, "linux,cma-default", NULL) ||
> +           of_get_flat_dt_prop(node, "linux,dma-default", NULL) ||
> +           of_get_flat_dt_prop(node, "no-map", NULL))
> +               return -EINVAL;
> +
> +       if (PageHighMem(pfn_to_page(PHYS_PFN(rmem->base)))) {
> +               pr_err("Restricted DMA pool must be accessible within the linear mapping.");
> +               return -EINVAL;
> +       }
> +
> +       rmem->ops = &rmem_swiotlb_ops;
> +       pr_info("Reserved memory: created restricted DMA pool at %pa, size %ld MiB\n",
> +               &rmem->base, (unsigned long)rmem->size / SZ_1M);

Oh là là, besides explicit casting that I believe can be avoided, %ld
!= unsigned long. Can you check the printk-formats.rst document?

> +       return 0;
> +}
> +
> +RESERVEDMEM_OF_DECLARE(dma, "restricted-dma-pool", rmem_swiotlb_setup);
>  #endif /* CONFIG_DMA_RESTRICTED_POOL */

-- 
With Best Regards,
Andy Shevchenko

WARNING: multiple messages have this Message-ID (diff)
From: Andy Shevchenko <andy.shevchenko@gmail.com>
To: Claire Chang <tientzu@chromium.org>
Cc: heikki.krogerus@linux.intel.com,
	thomas.hellstrom@linux.intel.com, peterz@infradead.org,
	joonas.lahtinen@linux.intel.com, dri-devel@lists.freedesktop.org,
	chris@chris-wilson.co.uk, grant.likely@arm.com, paulus@samba.org,
	Frank Rowand <frowand.list@gmail.com>,
	mingo@kernel.org, Marek Szyprowski <m.szyprowski@samsung.com>,
	sstabellini@kernel.org, Saravana Kannan <saravanak@google.com>,
	Joerg Roedel <joro@8bytes.org>,
	"Rafael J . Wysocki" <rafael.j.wysocki@intel.com>,
	Christoph Hellwig <hch@lst.de>,
	Bartosz Golaszewski <bgolaszewski@baylibre.com>,
	bskeggs@redhat.com, linux-pci@vger.kernel.org,
	xen-devel@lists.xenproject.org,
	Thierry Reding <treding@nvidia.com>,
	intel-gfx@lists.freedesktop.org, matthew.auld@intel.com,
	linux-devicetree <devicetree@vger.kernel.org>,
	jxgao@google.com, daniel@ffwll.ch, Will Deacon <will@kernel.org>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	maarten.lankhorst@linux.intel.com, airlied@linux.ie,
	Dan Williams <dan.j.williams@intel.com>,
	linuxppc-dev@lists.ozlabs.org, jani.nikula@linux.intel.com,
	Rob Herring <robh+dt@kernel.org>,
	rodrigo.vivi@intel.com, bhelgaas@google.com,
	Boris Ostrovsky <boris.ostrovsky@oracle.com>,
	Andy Shevchenko <andriy.shevchenko@linux.intel.com>,
	Juergen Gross <jgross@suse.com>,
	Nicolas Boichat <drinkcat@chromium.org>,
	Greg KH <gregkh@linuxfoundation.org>,
	Randy Dunlap <rdunlap@infradead.org>,
	quic_qiancai@quicinc.com, lkml <linux-kernel@vger.kernel.org>,
	tfiga@chromium.org,
	"list@263.net:IOMMU DRIVERS" <iommu@lists.linux-foundation.org>,
	Jim Quinlan <james.quinlan@broadcom.com>,
	xypron.glpk@gmx.de, thomas.lendacky@amd.com,
	Robin Murphy <robin.murphy@arm.com>,
	bauerman@linux.ibm.com
Subject: Re: [PATCH v15 10/12] swiotlb: Add restricted DMA pool initialization
Date: Fri, 27 Aug 2021 09:58:32 +0300	[thread overview]
Message-ID: <CAHp75VfVhVGFEQGeUKajrUKmkx_et_KakDDgroC2BrMMhd62yg@mail.gmail.com> (raw)
In-Reply-To: <20210624155526.2775863-11-tientzu@chromium.org>

On Thu, Jun 24, 2021 at 6:59 PM Claire Chang <tientzu@chromium.org> wrote:
>
> Add the initialization function to create restricted DMA pools from
> matching reserved-memory nodes.
>
> Regardless of swiotlb setting, the restricted DMA pool is preferred if
> available.
>
> The restricted DMA pools provide a basic level of protection against the
> DMA overwriting buffer contents at unexpected times. However, to protect
> against general data leakage and system memory corruption, the system
> needs to provide a way to lock down the memory access, e.g., MPU.





> +static int rmem_swiotlb_device_init(struct reserved_mem *rmem,
> +                                   struct device *dev)
> +{
> +       struct io_tlb_mem *mem = rmem->priv;
> +       unsigned long nslabs = rmem->size >> IO_TLB_SHIFT;
> +
> +       /*
> +        * Since multiple devices can share the same pool, the private data,
> +        * io_tlb_mem struct, will be initialized by the first device attached
> +        * to it.
> +        */

> +       if (!mem) {

Can it be rather

if (mem)
  goto out_assign;

or so?

> +               mem = kzalloc(struct_size(mem, slots, nslabs), GFP_KERNEL);
> +               if (!mem)
> +                       return -ENOMEM;
> +
> +               set_memory_decrypted((unsigned long)phys_to_virt(rmem->base),
> +                                    rmem->size >> PAGE_SHIFT);

Below you are using a macro from pfn.h, but not here, I think it's PFN_DOWN().

> +               swiotlb_init_io_tlb_mem(mem, rmem->base, nslabs, false);
> +               mem->force_bounce = true;
> +               mem->for_alloc = true;
> +
> +               rmem->priv = mem;
> +
> +               if (IS_ENABLED(CONFIG_DEBUG_FS)) {
> +                       mem->debugfs =
> +                               debugfs_create_dir(rmem->name, debugfs_dir);
> +                       swiotlb_create_debugfs_files(mem);
> +               }
> +       }
> +
> +       dev->dma_io_tlb_mem = mem;
> +
> +       return 0;
> +}
> +
> +static void rmem_swiotlb_device_release(struct reserved_mem *rmem,
> +                                       struct device *dev)
> +{
> +       dev->dma_io_tlb_mem = io_tlb_default_mem;
> +}
> +
> +static const struct reserved_mem_ops rmem_swiotlb_ops = {
> +       .device_init = rmem_swiotlb_device_init,
> +       .device_release = rmem_swiotlb_device_release,
> +};
> +
> +static int __init rmem_swiotlb_setup(struct reserved_mem *rmem)
> +{
> +       unsigned long node = rmem->fdt_node;
> +
> +       if (of_get_flat_dt_prop(node, "reusable", NULL) ||
> +           of_get_flat_dt_prop(node, "linux,cma-default", NULL) ||
> +           of_get_flat_dt_prop(node, "linux,dma-default", NULL) ||
> +           of_get_flat_dt_prop(node, "no-map", NULL))
> +               return -EINVAL;
> +
> +       if (PageHighMem(pfn_to_page(PHYS_PFN(rmem->base)))) {
> +               pr_err("Restricted DMA pool must be accessible within the linear mapping.");
> +               return -EINVAL;
> +       }
> +
> +       rmem->ops = &rmem_swiotlb_ops;
> +       pr_info("Reserved memory: created restricted DMA pool at %pa, size %ld MiB\n",
> +               &rmem->base, (unsigned long)rmem->size / SZ_1M);

Oh là là, besides explicit casting that I believe can be avoided, %ld
!= unsigned long. Can you check the printk-formats.rst document?

> +       return 0;
> +}
> +
> +RESERVEDMEM_OF_DECLARE(dma, "restricted-dma-pool", rmem_swiotlb_setup);
>  #endif /* CONFIG_DMA_RESTRICTED_POOL */

-- 
With Best Regards,
Andy Shevchenko

  parent reply	other threads:[~2021-08-27  6:59 UTC|newest]

Thread overview: 245+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-06-24 15:55 [PATCH v15 00/12] Restricted DMA Claire Chang
2021-06-24 15:55 ` [Intel-gfx] " Claire Chang
2021-06-24 15:55 ` Claire Chang
2021-06-24 15:55 ` Claire Chang
2021-06-24 15:55 ` Claire Chang
2021-06-24 15:55 ` [PATCH v15 01/12] swiotlb: Refactor swiotlb init functions Claire Chang
2021-06-24 15:55   ` [Intel-gfx] " Claire Chang
2021-06-24 15:55   ` Claire Chang
2021-06-24 15:55   ` Claire Chang
2021-06-24 15:55   ` Claire Chang
2021-06-24 15:55 ` [PATCH v15 02/12] swiotlb: Refactor swiotlb_create_debugfs Claire Chang
2021-06-24 15:55   ` [Intel-gfx] " Claire Chang
2021-06-24 15:55   ` Claire Chang
2021-06-24 15:55   ` Claire Chang
2021-06-24 15:55   ` Claire Chang
2021-06-24 15:55 ` [PATCH v15 03/12] swiotlb: Set dev->dma_io_tlb_mem to the swiotlb pool used Claire Chang
2021-06-24 15:55   ` [Intel-gfx] " Claire Chang
2021-06-24 15:55   ` Claire Chang
2021-06-24 15:55   ` Claire Chang
2021-06-24 15:55   ` Claire Chang
2021-06-24 15:55 ` [PATCH v15 04/12] swiotlb: Update is_swiotlb_buffer to add a struct device argument Claire Chang
2021-06-24 15:55   ` [Intel-gfx] " Claire Chang
2021-06-24 15:55   ` Claire Chang
2021-06-24 15:55   ` Claire Chang
2021-06-24 15:55   ` Claire Chang
2021-06-24 15:55 ` [PATCH v15 05/12] swiotlb: Update is_swiotlb_active " Claire Chang
2021-06-24 15:55   ` [Intel-gfx] " Claire Chang
2021-06-24 15:55   ` Claire Chang
2021-06-24 15:55   ` Claire Chang
2021-06-24 15:55   ` Claire Chang
2021-06-24 15:55 ` [PATCH v15 06/12] swiotlb: Use is_swiotlb_force_bounce for swiotlb data bouncing Claire Chang
2021-06-24 15:55   ` [Intel-gfx] " Claire Chang
2021-06-24 15:55   ` Claire Chang
2021-06-24 15:55   ` Claire Chang
2021-06-24 15:55   ` Claire Chang
2021-06-30  1:43   ` Nathan Chancellor
2021-06-30  1:43     ` [Intel-gfx] " Nathan Chancellor
2021-06-30  1:43     ` Nathan Chancellor
2021-06-30  1:43     ` Nathan Chancellor
2021-06-30  1:43     ` Nathan Chancellor
2021-06-30  9:17     ` Claire Chang
2021-06-30  9:17       ` Claire Chang
2021-06-30  9:17       ` [Intel-gfx] " Claire Chang
2021-06-30  9:17       ` Claire Chang
2021-06-30  9:17       ` Claire Chang
2021-06-30  9:17       ` Claire Chang
2021-06-30 11:43       ` Will Deacon
2021-06-30 11:43         ` [Intel-gfx] " Will Deacon
2021-06-30 11:43         ` Will Deacon
2021-06-30 11:43         ` Will Deacon
2021-06-30 11:43         ` Will Deacon
2021-06-30 15:56         ` Nathan Chancellor
2021-06-30 15:56           ` [Intel-gfx] " Nathan Chancellor
2021-06-30 15:56           ` Nathan Chancellor
2021-06-30 15:56           ` Nathan Chancellor
2021-06-30 15:56           ` Nathan Chancellor
2021-07-01  7:40           ` Will Deacon
2021-07-01  7:40             ` [Intel-gfx] " Will Deacon
2021-07-01  7:40             ` Will Deacon
2021-07-01  7:40             ` Will Deacon
2021-07-01  7:40             ` Will Deacon
2021-07-01  7:52             ` Nathan Chancellor
2021-07-01  7:52               ` [Intel-gfx] " Nathan Chancellor
2021-07-01  7:52               ` Nathan Chancellor
2021-07-01  7:52               ` Nathan Chancellor
2021-07-01  7:52               ` Nathan Chancellor
2021-07-02 13:58               ` Will Deacon
2021-07-02 13:58                 ` [Intel-gfx] " Will Deacon
2021-07-02 13:58                 ` Will Deacon
2021-07-02 13:58                 ` Will Deacon
2021-07-02 13:58                 ` Will Deacon
2021-07-02 15:13                 ` Robin Murphy
2021-07-02 15:13                   ` [Intel-gfx] " Robin Murphy
2021-07-02 15:13                   ` Robin Murphy
2021-07-02 15:13                   ` Robin Murphy
2021-07-02 15:13                   ` Robin Murphy
2021-07-03  5:55                   ` Nathan Chancellor
2021-07-03  5:55                     ` [Intel-gfx] " Nathan Chancellor
2021-07-03  5:55                     ` Nathan Chancellor
2021-07-03  5:55                     ` Nathan Chancellor
2021-07-03  5:55                     ` Nathan Chancellor
2021-07-05  7:29                     ` Claire Chang
2021-07-05  7:29                       ` Claire Chang
2021-07-05  7:29                       ` [Intel-gfx] " Claire Chang
2021-07-05  7:29                       ` Claire Chang
2021-07-05  7:29                       ` Claire Chang
2021-07-05  7:29                       ` Claire Chang
2021-07-05 18:25                       ` Nathan Chancellor
2021-07-05 18:25                         ` [Intel-gfx] " Nathan Chancellor
2021-07-05 18:25                         ` Nathan Chancellor
2021-07-05 18:25                         ` Nathan Chancellor
2021-07-05 18:25                         ` Nathan Chancellor
2021-07-05 19:03                     ` Will Deacon
2021-07-05 19:03                       ` [Intel-gfx] " Will Deacon
2021-07-05 19:03                       ` Will Deacon
2021-07-05 19:03                       ` Will Deacon
2021-07-05 19:03                       ` Will Deacon
2021-07-06  4:48                       ` Christoph Hellwig
2021-07-06  4:48                         ` [Intel-gfx] " Christoph Hellwig
2021-07-06  4:48                         ` Christoph Hellwig
2021-07-06  4:48                         ` Christoph Hellwig
2021-07-06 13:24                         ` Will Deacon
2021-07-06 13:24                           ` [Intel-gfx] " Will Deacon
2021-07-06 13:24                           ` Will Deacon
2021-07-06 13:24                           ` Will Deacon
2021-07-06 13:24                           ` Will Deacon
2021-07-06 14:01                           ` Robin Murphy
2021-07-06 14:01                             ` [Intel-gfx] " Robin Murphy
2021-07-06 14:01                             ` Robin Murphy
2021-07-06 14:01                             ` Robin Murphy
2021-07-06 14:01                             ` Robin Murphy
2021-07-06 14:05                             ` Christoph Hellwig
2021-07-06 14:05                               ` [Intel-gfx] " Christoph Hellwig
2021-07-06 14:05                               ` Christoph Hellwig
2021-07-06 14:05                               ` Christoph Hellwig
2021-07-06 14:46                               ` Konrad Rzeszutek Wilk
2021-07-06 14:46                                 ` [Intel-gfx] " Konrad Rzeszutek Wilk
2021-07-06 14:46                                 ` Konrad Rzeszutek Wilk
2021-07-06 14:46                                 ` Konrad Rzeszutek Wilk
2021-07-06 14:46                                 ` Konrad Rzeszutek Wilk
2021-07-06 16:57                                 ` Will Deacon
2021-07-06 16:57                                   ` [Intel-gfx] " Will Deacon
2021-07-06 16:57                                   ` Will Deacon
2021-07-06 16:57                                   ` Will Deacon
2021-07-06 16:57                                   ` Will Deacon
2021-07-06 16:59                                   ` Konrad Rzeszutek Wilk
2021-07-06 16:59                                     ` [Intel-gfx] " Konrad Rzeszutek Wilk
2021-07-06 16:59                                     ` Konrad Rzeszutek Wilk
2021-07-06 16:59                                     ` Konrad Rzeszutek Wilk
2021-07-06 16:59                                     ` Konrad Rzeszutek Wilk
2021-07-12 13:56                                     ` Will Deacon
2021-07-12 13:56                                       ` [Intel-gfx] " Will Deacon
2021-07-12 13:56                                       ` Will Deacon
2021-07-12 13:56                                       ` Will Deacon
2021-07-12 13:56                                       ` Will Deacon
2021-07-14  0:06                                       ` Konrad Rzeszutek Wilk
2021-07-14  0:06                                         ` [Intel-gfx] " Konrad Rzeszutek Wilk
2021-07-14  0:06                                         ` Konrad Rzeszutek Wilk
2021-07-14  0:06                                         ` Konrad Rzeszutek Wilk
2021-07-14  0:06                                         ` Konrad Rzeszutek Wilk
2021-07-06 15:39                               ` Robin Murphy
2021-07-06 15:39                                 ` [Intel-gfx] " Robin Murphy
2021-07-06 15:39                                 ` Robin Murphy
2021-07-06 15:39                                 ` Robin Murphy
2021-07-06 15:39                                 ` Robin Murphy
2021-07-06 17:06                                 ` Will Deacon
2021-07-06 17:06                                   ` [Intel-gfx] " Will Deacon
2021-07-06 17:06                                   ` Will Deacon
2021-07-06 17:06                                   ` Will Deacon
2021-07-06 17:06                                   ` Will Deacon
2021-07-06 19:14                                   ` Nathan Chancellor
2021-07-06 19:14                                     ` [Intel-gfx] " Nathan Chancellor
2021-07-06 19:14                                     ` Nathan Chancellor
2021-07-06 19:14                                     ` Nathan Chancellor
2021-07-06 19:14                                     ` Nathan Chancellor
2021-07-08 16:44                                     ` Will Deacon
2021-07-08 16:44                                       ` [Intel-gfx] " Will Deacon
2021-07-08 16:44                                       ` Will Deacon
2021-07-08 16:44                                       ` Will Deacon
2021-07-08 16:44                                       ` Will Deacon
2021-06-24 15:55 ` [PATCH v15 07/12] swiotlb: Move alloc_size to swiotlb_find_slots Claire Chang
2021-06-24 15:55   ` [Intel-gfx] " Claire Chang
2021-06-24 15:55   ` Claire Chang
2021-06-24 15:55   ` Claire Chang
2021-06-24 15:55   ` Claire Chang
2021-06-24 15:55 ` [PATCH v15 08/12] swiotlb: Refactor swiotlb_tbl_unmap_single Claire Chang
2021-06-24 15:55   ` [Intel-gfx] " Claire Chang
2021-06-24 15:55   ` Claire Chang
2021-06-24 15:55   ` Claire Chang
2021-06-24 15:55   ` Claire Chang
2021-06-24 15:55 ` [PATCH v15 09/12] swiotlb: Add restricted DMA alloc/free support Claire Chang
2021-06-24 15:55   ` [Intel-gfx] " Claire Chang
2021-06-24 15:55   ` Claire Chang
2021-06-24 15:55   ` Claire Chang
2021-06-24 15:55   ` Claire Chang
2021-06-24 15:55 ` [PATCH v15 10/12] swiotlb: Add restricted DMA pool initialization Claire Chang
2021-06-24 15:55   ` [Intel-gfx] " Claire Chang
2021-06-24 15:55   ` Claire Chang
2021-06-24 15:55   ` Claire Chang
2021-06-24 15:55   ` Claire Chang
2021-08-24 14:26   ` Guenter Roeck
2021-08-24 14:26     ` Guenter Roeck
2021-08-24 14:26     ` [Intel-gfx] " Guenter Roeck
2021-08-24 14:26     ` Guenter Roeck
2021-08-27  3:50     ` Claire Chang
2021-08-27  3:50       ` Claire Chang
2021-08-27  3:50       ` [Intel-gfx] " Claire Chang
2021-08-27  3:50       ` Claire Chang
2021-08-27  3:50       ` Claire Chang
2021-08-27  3:50       ` Claire Chang
2021-08-27  6:58   ` Andy Shevchenko [this message]
2021-08-27  6:58     ` Andy Shevchenko
2021-08-27  6:58     ` [Intel-gfx] " Andy Shevchenko
2021-08-27  6:58     ` Andy Shevchenko
2021-08-27  6:58     ` Andy Shevchenko
2021-06-24 15:55 ` [PATCH v15 11/12] dt-bindings: of: Add restricted DMA pool Claire Chang
2021-06-24 15:55   ` [Intel-gfx] " Claire Chang
2021-06-24 15:55   ` Claire Chang
2021-06-24 15:55   ` Claire Chang
2021-06-24 15:55   ` Claire Chang
2021-06-24 15:55 ` [PATCH v15 12/12] of: Add plumbing for " Claire Chang
2021-06-24 15:55   ` [Intel-gfx] " Claire Chang
2021-06-24 15:55   ` Claire Chang
2021-06-24 15:55   ` Claire Chang
2021-06-24 15:55   ` Claire Chang
2021-07-02  3:08   ` Guenter Roeck
2021-07-02  3:08     ` [Intel-gfx] " Guenter Roeck
2021-07-02  3:08     ` Guenter Roeck
2021-07-02  3:08     ` Guenter Roeck
2021-07-02  3:08     ` Guenter Roeck
2021-07-02 11:39     ` Robin Murphy
2021-07-02 11:39       ` [Intel-gfx] " Robin Murphy
2021-07-02 11:39       ` Robin Murphy
2021-07-02 11:39       ` Robin Murphy
2021-07-02 11:39       ` Robin Murphy
2021-07-02 13:18       ` Will Deacon
2021-07-02 13:18         ` [Intel-gfx] " Will Deacon
2021-07-02 13:18         ` Will Deacon
2021-07-02 13:18         ` Will Deacon
2021-07-02 13:18         ` Will Deacon
2021-07-02 13:48         ` Guenter Roeck
2021-07-02 13:48           ` [Intel-gfx] " Guenter Roeck
2021-07-02 13:48           ` Guenter Roeck
2021-07-02 13:48           ` Guenter Roeck
2021-07-02 13:48           ` Guenter Roeck
2021-06-24 16:42 ` [Intel-gfx] ✗ Fi.CI.BUILD: failure for Restricted DMA Patchwork
2021-06-24 19:19 ` [PATCH v15 00/12] " Konrad Rzeszutek Wilk
2021-06-24 19:19   ` [Intel-gfx] " Konrad Rzeszutek Wilk
2021-06-24 19:19   ` Konrad Rzeszutek Wilk
2021-06-24 19:19   ` Konrad Rzeszutek Wilk
2021-06-24 19:19   ` Konrad Rzeszutek Wilk
2021-06-25  0:41   ` Claire Chang
2021-06-25  0:41     ` Claire Chang
2021-06-25  0:41     ` [Intel-gfx] " Claire Chang
2021-06-25  0:41     ` Claire Chang
2021-06-25  0:41     ` Claire Chang
2021-06-25  0:41     ` Claire Chang
2021-06-25 12:30   ` Will Deacon
2021-06-25 12:30     ` [Intel-gfx] " Will Deacon
2021-06-25 12:30     ` Will Deacon
2021-06-25 12:30     ` Will Deacon
2021-06-25 12:30     ` Will Deacon
2021-07-02 15:48 ` [Intel-gfx] ✗ Fi.CI.BUILD: failure for Restricted DMA (rev2) Patchwork
2021-07-05  7:57 ` [Intel-gfx] ✗ Fi.CI.BUILD: failure for Restricted DMA (rev3) Patchwork
2021-07-06 18:57 ` [Intel-gfx] ✗ Fi.CI.BUILD: failure for Restricted DMA (rev5) Patchwork

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CAHp75VfVhVGFEQGeUKajrUKmkx_et_KakDDgroC2BrMMhd62yg@mail.gmail.com \
    --to=andy.shevchenko@gmail.com \
    --cc=airlied@linux.ie \
    --cc=andriy.shevchenko@linux.intel.com \
    --cc=bauerman@linux.ibm.com \
    --cc=benh@kernel.crashing.org \
    --cc=bgolaszewski@baylibre.com \
    --cc=bhelgaas@google.com \
    --cc=boris.ostrovsky@oracle.com \
    --cc=bskeggs@redhat.com \
    --cc=chris@chris-wilson.co.uk \
    --cc=dan.j.williams@intel.com \
    --cc=daniel@ffwll.ch \
    --cc=devicetree@vger.kernel.org \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=drinkcat@chromium.org \
    --cc=frowand.list@gmail.com \
    --cc=grant.likely@arm.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=hch@lst.de \
    --cc=heikki.krogerus@linux.intel.com \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=iommu@lists.linux-foundation.org \
    --cc=james.quinlan@broadcom.com \
    --cc=jani.nikula@linux.intel.com \
    --cc=jgross@suse.com \
    --cc=joonas.lahtinen@linux.intel.com \
    --cc=joro@8bytes.org \
    --cc=jxgao@google.com \
    --cc=konrad.wilk@oracle.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=linuxppc-dev@lists.ozlabs.org \
    --cc=m.szyprowski@samsung.com \
    --cc=maarten.lankhorst@linux.intel.com \
    --cc=matthew.auld@intel.com \
    --cc=mingo@kernel.org \
    --cc=mpe@ellerman.id.au \
    --cc=paulus@samba.org \
    --cc=peterz@infradead.org \
    --cc=quic_qiancai@quicinc.com \
    --cc=rafael.j.wysocki@intel.com \
    --cc=rdunlap@infradead.org \
    --cc=robh+dt@kernel.org \
    --cc=robin.murphy@arm.com \
    --cc=rodrigo.vivi@intel.com \
    --cc=saravanak@google.com \
    --cc=sstabellini@kernel.org \
    --cc=tfiga@chromium.org \
    --cc=thomas.hellstrom@linux.intel.com \
    --cc=thomas.lendacky@amd.com \
    --cc=tientzu@chromium.org \
    --cc=treding@nvidia.com \
    --cc=will@kernel.org \
    --cc=xen-devel@lists.xenproject.org \
    --cc=xypron.glpk@gmx.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.