On Wed, Apr 3, 2013 at 2:18 PM, Scott Wood <scottw...@freescale.com> wrote: > On 04/03/2013 02:09:45 PM, Stuart Yoder wrote: >> >> > Would is be possible for userspace to simply leave room for MSI bank >> > mapping (how much room could be determined by something like >> > VFIO_IOMMU_GET_MSI_BANK_COUNT) then document the API that userspace can >> > DMA_MAP starting at the 0x0 address of the aperture, growing up, and >> > VFIO will map banks on demand at the top of the aperture, growing down? >> > Wouldn't that avoid a lot of issues with userspace needing to know >> > anything about MSI banks (other than count) and coordinating irq numbers >> > and enabling handlers? >> >> This is basically option #A in the original proposals sent. I like >> this approach, in that it >> is simpler and keeps user space mostly out of this...which is >> consistent with how things are done >> on x86. User space just needs to know how many windows to leave at >> the top of the aperture. >> The kernel then has the flexibility to use those windows how it wants. >> >> But one question, is when should the kernel actually map (and unmap) >> the MSI banks. > > > I think userspace should explicitly request it. Userspace still wouldn't > need to know anything but the count: > > count = VFIO_IOMMU_GET_MSI_BANK_COUNT > VFIO_IOMMU_SET_ATTR(ATTR_GEOMETRY) > VFIO_IOMMU_SET_ATTR(ATTR_WINDOWS) > // do other DMA maps now, or later, or not at all, doesn't matter > for (i = 0; i < count; i++) > VFIO_IOMMU_MAP_MSI_BANK(iova, i); > // The kernel now knows where each bank has been mapped, and can update PCI > config space appropriately.
And the overall aperture enable/disable would occur on the first dma/msi map() and last dma/msi unmap()? Stuart
