Re: [PATCH] PCI: tegra: Do not allocate MSI target memory

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 





On 3/2/2019 7:52 PM, Lucas Stach wrote:
Am Samstag, den 02.03.2019, 08:20 +0530 schrieb Vidya Sagar:
On 3/1/2019 8:26 PM, Lucas Stach wrote:
Am Freitag, den 01.03.2019, 08:45 +0530 schrieb Vidya Sagar:
On 3/1/2019 12:32 AM, Lucas Stach wrote:
Am Donnerstag, den 28.02.2019, 20:30 +0530 schrieb Vidya Sagar:
The PCI host bridge found on Tegra SoCs doesn't require the MSI target
address to be backed by physical system memory. Writes are intercepted
within the controller and never make it to the memory pointed to.

Since no actual system memory is required, remove the allocation of a
single page and hardcode the MSI target address with a special address
on a per-SoC basis. Ideally this would be an address to an MMIO memory
region (such as where the controller's register are located). However,
those addresses don't work reliably across all Tegra generations. The
only set of addresses that work consistently are those that point to
external memory.

This is not ideal, since those addresses could technically be used for
DMA and hence be confusing. However, the first page of external memory
is unlikely to be used and special enough to avoid confusion.
So you are trading a slight memory waste of a single page against a
sporadic (and probably hard to debug) DMA failure if any device happens
to initiate DMA to the first page of physical memory? That does not
sound like a good deal...

Also why would the first page of external memory be unlikely to be
used?

Regards,
Lucas
We are not wasting single page of memory here and if any device's DMA is
trying to access it, it will still go through. Its just that we are using that
same address for MSI (note that MSI writes don't go beyond PCIe IP as they get
decoded at PCIe IP level itself and only an interrupt
goes to CPU) and that might be a bit confusing as same address is used
as normal memory as well as MSI target address. Since there can never be any
issue with this would you suggest to remove the last paragraph from commit
description?
How does the core distinguish between a normal DMA memory write and a
MSI? If I remember the PCIe spec correctly, there aren't any
differences between the two besides the target address.

So if you now set a non-reserved region of memory to decode as a MSI at
the PCIe host controller level, wouldn't this lead to normal DMA
transactions to this address being wrongfully turned into an MSI and
the write not reaching the targeted location?

Regards,
Lucas
You are correct that core cannot distinguish between a normal DMA memory and
MSI. In that case, the only way I see is to alloc memory using
dma_alloc_coherent()
and use the IOVA as the MSI target address. That way, a page gets
reserved (in a way wasted
also as the MSI writes don't really make it to RAM) and there won't be
any address
overlaps with normal DMA writes. I'll push a patch for it.
At that point it's no longer different from the current code, which
simply reserves a single page of memory and uses its address as the MSI
target address.
But, I think there is still one issue with the current code base. Since what is used as MSI target address is the physical address equivalent of the memory page being reserved, there is a chance that some IOVA might become equal to this physical address there by making PCIe IP to raise an MSI interrupt instead of forwarding the write to memory.
Do you agree with this?
So in conclusion this change should just be dropped.

Regards,
Lucas





[Index of Archives]     [DMA Engine]     [Linux Coverity]     [Linux USB]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [Greybus]

  Powered by Linux