On Tue, 22 May 2018 16:51:26 -0500 Bjorn Helgaas <helgaas@xxxxxxxxxx> wrote: > [+cc Alex] > > On Tue, May 22, 2018 at 02:09:59PM -0700, Doug Meyer wrote: > > Logan answered the questions quite thoroughly. (Thanks, Logan!) > > When you repost it, please rework the commit log so it answers the > questions directly. Otherwise the next reader may have the same > questions again. E.g., say something about how the proxy IDs are not > programmable and are fixed in the hardware so all we have to do is > read them. > > I don't think the question of when the aliases need to be added is > quite closed. Logan said "it seems pci_add_dma_alias() must be called > before the driver is initialized and therefore in a quirk", but that > doesn't make clear *why* the alias needs to be added before the driver > is initialized. The alias shouldn't be needed until the device does a > DMA, and it shouldn't do that until after the driver initializes. Aliases for devices that don't have a representation on the bus is only one use for pci_add_dma_alias(), we can also use it when the aliased device is visible on the bus and then it factors not only into the IOMMU context entries for a given device, but also the grouping of multiple devices that must be done without a host endpoint driver. > I suspect the reason the existing quirks are in drivers/pci/quirks.c > is because the IOMMU driver is in the host OS, but the host may not > have a driver for the device if the device is passed through to a > guest OS. In that case, the only way to add the alias is by using a > quirk that is always built into the host OS. > > We could argue that the driver in the guest should be able to tell the > host's IOMMU driver about these aliases, but I doubt there's an > interface for that. Sounds like a dangerous interface, imagine two physical functions on a device, each assigned to separate guests where one guest could usurp context entries for hidden devices from the other guest. Thanks, Alex
