On 04/03/2013 02:43:06 PM, Stuart Yoder wrote:
On Wed, Apr 3, 2013 at 2:18 PM, Scott Wood <scottwood@xxxxxxxxxxxxx>
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()?
Yes. We may want the optional ability to do an overall enable/disable
for reasons we discussed a while ago, but in the absence of an explicit
disable the domain would be enabled on first map.
-Scott
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
