linux-kernel - RE: [PATCH 2/2] dmaengine: dw-edma: Add non-LL mode

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID:
 <SA1PR12MB81204E8706B7EB7AB662573C9508A@SA1PR12MB8120.namprd12.prod.outlook.com>
Date: Fri, 12 Sep 2025 09:31:10 +0000
From: "Verma, Devendra" <Devendra.Verma@....com>
To: Bjorn Helgaas <helgaas@...nel.org>
CC: "bhelgaas@...gle.com" <bhelgaas@...gle.com>, "mani@...nel.org"
	<mani@...nel.org>, "vkoul@...nel.org" <vkoul@...nel.org>,
	"dmaengine@...r.kernel.org" <dmaengine@...r.kernel.org>,
	"linux-pci@...r.kernel.org" <linux-pci@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>, "Simek,
 Michal" <michal.simek@....com>
Subject: RE: [PATCH 2/2] dmaengine: dw-edma: Add non-LL mode

[AMD Official Use Only - AMD Internal Distribution Only]

Hi Bjorn

Please check my response inline.
Regards,
Devendra

> -----Original Message-----
> From: Bjorn Helgaas <helgaas@...nel.org>
> Sent: Friday, September 12, 2025 02:14
> To: Verma, Devendra <Devendra.Verma@....com>
> Cc: bhelgaas@...gle.com; mani@...nel.org; vkoul@...nel.org;
> dmaengine@...r.kernel.org; linux-pci@...r.kernel.org; linux-
> kernel@...r.kernel.org; Simek, Michal <michal.simek@....com>
> Subject: Re: [PATCH 2/2] dmaengine: dw-edma: Add non-LL mode
>
> Caution: This message originated from an External Source. Use proper caution
> when opening attachments, clicking links, or responding.
>
>
> On Thu, Sep 11, 2025 at 11:42:31AM +0000, Verma, Devendra wrote:
> > > -----Original Message-----
> > > From: Bjorn Helgaas <helgaas@...nel.org>
>
> > > On Wed, Sep 10, 2025 at 12:30:39PM +0000, Verma, Devendra wrote:
> > > > > From: Bjorn Helgaas <helgaas@...nel.org>
> > >
> > > [redundant headers removed]
> > >
> > > > > On Fri, Sep 05, 2025 at 03:46:59PM +0530, Devendra K Verma wrote:
> > > > > > AMD MDB IP supports Linked List (LL) mode as well as non-LL mode.
> > > > > > The current code does not have the mechanisms to enable the
> > > > > > DMA transactions using the non-LL mode. The following two
> > > > > > cases are added with this patch:
> > >
> > > > > > +static u64 dw_edma_get_phys_addr(struct pci_dev *pdev,
> > > > > > +                              struct dw_edma_pcie_data *pdata,
> > > > > > +                              enum pci_barno bar) {
> > > > > > +     if (pdev->vendor == PCI_VENDOR_ID_XILINX)
> > > > > > +             return pdata->phys_addr;
> > > > > > +     return pci_bus_address(pdev, bar);
> > > > >
> > > > > This doesn't seem right.  pci_bus_address() returns
> > > > > pci_bus_addr_t, so pdata->phys_addr should also be a
> > > > > pci_bus_addr_t, and the function should return pci_bus_addr_t.
> > > > >
> > > > > A pci_bus_addr_t is not a "phys_addr"; it is an address that is
> > > > > valid on the PCI side of a PCI host bridge, which may be
> > > > > different than the CPU physical address on the CPU side of the
> > > > > bridge because of things like IOMMUs.
> > > > >
> > > > > Seems like the struct dw_edma_region.paddr should be renamed to
> > > > > something like "bus_addr" and made into a pci_bus_addr_t.
> > > >
> > > > In case of AMD, it is not an address that is accessible from host
> > > > via PCI, it is the device side DDR offset of physical address
> > > > which is not known to host,that is why the VSEC capability is used
> > > > to let know host of the DDR offset to correctly programming the LLP of DMA
> controller.
> > > > Without programming the LLP controller will not know from where to
> > > > start reading the LL for DMA processing. DMA controller requires
> > > > the physical address of LL present on its side of DDR.
> > >
> > > I guess "device side DDR offset" means this Xilinx device has some
> > > DDR internal to the PCI device, and the CPU cannot access it via a
> > > BAR?
> >
> > The host can access the DDR internal to the PCI device via BAR, but it
> > involves an iATU translation. The host can use the virtual / physical
> > address to access that DDR.  The issue is not with the host rather DMA
> > controller which does not understand the physical address provided by
> > the host, eg, the address returned by pci_bus_addr(pdev, barno).
>
> Does this mean dw_edma_get_phys_addr() depends on iATU programming done by
> the PCI controller driver?  Is it possible for that driver to change the iATU
> programming after dw_edma_get_phys_addr() in a way that breaks this?
>

No, driver can neither program nor modify the iATU. Once device is configured using
AMD Programmable Device Image (PDI) which contains these configurations.
Once programmed the configuration can not be changed by the driver.

> Bjorn