On Mon, Mar 06, 2017 at 12:04:39PM +0100, Joerg Roedel wrote: > On Wed, Feb 22, 2017 at 05:39:44PM -0600, Bjorn Helgaas wrote: > > [+cc Joerg, iommu list] > > > > On Wed, Feb 22, 2017 at 03:44:53PM -0500, Sinan Kaya wrote: > > > On 2/22/2017 1:44 PM, Bjorn Helgaas wrote: > > > > There is no way for a driver to say "I only need this memory BAR and > > > > not the other ones." The reason is because the PCI_COMMAND_MEMORY bit > > > > enables *all* the memory BARs; there's no way to enable memory BARs > > > > selectively. If we enable memory BARs and one of them is unassigned, > > > > that unassigned BAR is enabled, and the device will respond at > > > > whatever address the register happens to contain, and that may cause > > > > conflicts. > > Hmm, maybe I am missing something, but isn't this only a problem if the > 'unassigned' BAR as an address configured that also falls into the > Bridge-Window of the parent bridge? Otherwise no requests should be > routed to the BAR anyway, right?
I guess it's true that we could safely enable a memory BAR if the upstream bridge would never route anything to it. But it would depend on the size of the BAR and the upstream bridge's configuration, so it doesn't feel like it would really be reliable in general. > > But if there *is* address translation in the PIO direction, we can > > have conflicts because the bridge can translate CPU-side PIO accesses > > to arbitrary PCI bus addresses. > > I am not aware of any hardware that does translation on the PIO space. > The IOMMUs I know of don't care about PIO at all. Right, address translation in the PIO direction would be done by the host bridge, not the IOMMU. There are a fair number of bridges that do this -- basically all the callers of pci_add_resource_offset(). They just apply a constant offset, often by chopping off some high-order bits of the CPU address. Bjorn _______________________________________________ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
