> -----Original Message----- > From: Alex Williamson [mailto:alex.williamson@xxxxxxxxxx] > Sent: Friday, December 2, 2016 1:23 AM > To: Ilya Lesokhin <ilyal@xxxxxxxxxxxx> > Cc: linux-pci@xxxxxxxxxxxxxxx; kvm@xxxxxxxxxxxxxxx; bhelgaas@xxxxxxxxxx; > Adi Menachem <adim@xxxxxxxxxxxx> > Subject: Re: Shouldn't VFIO virtualize the ATS capability? ... > > > > > Aren't invalidations issued by the iommu, why does the > > > > > hypervisor need to participate? How would a software entity > > > > > induce an > > > invalidation? > > > > That's what one might expect from a sane design, but > > > > http://lxr.free-electrons.com/source/drivers/iommu/intel-iommu.c?v > > > > =4.8 > > > > #L1549 > > > > seems to imply otherwise :( > > This seems correct though, the device iotlb would interact with the physical > IOMMU, so this is happening on the host. The call path would > be: > > ioctl(container, VFIO_IOMMU_UNMAP_DMA, ...) > vfio_fops_unl_ioctl > vfio_iommu_type1_ioctl > vfio_dma_do_unmap > vfio_remove_dma > vfio_unmap_unpin > iommu_unmap > intel_iommu_unmap > iommu_flush_iotlb_psi > iommu_flush_dev_iotlb > > For a non-iommu VM, mappings will be mostly static, so this will be rare. If > we had VT-d emulation support in the VM, the iommu domain used by the > VM would map to an iommu domain in the host and any invalidations within > that domain would trigger an unmap through to the host domain. My concern was for the case where the host is not aware of ATS or decides not to use it for some reason. In that case the guest might enable ATS and abuse the fact that the host doesn't know it needs to issue invalidations to the device > > > > > > > 2. Smallest Translation Unit misconfiguration. Not sure if it > > > > > > will cause > > > > > invalid access or only poor caching behavior. > > I'm not sure about this either. I think that ATS is enabled on the > device prior to the guest having access to it, but could the guest > interfere or cause poor behavior by further interaction with the ATS > capability. I guess my question would be whether the guest needs > visibility or access to the ATS capability to still make use of it. We > certainly want to take advantage of an iotlb where available. For a > Linux guest we only seem to manipulate ATS enable through the iommu > code, so I expect a non-iommu VM to leave ATS alone. What's the best > solution then, to hide the ATS capability, assuming that it works > transparently on the host level? Expose it to the guest, perhaps > virtualizing the STU field to the VM, giving the VM enable/disable > control? How can we test any of this? Thanks, > I don't see the benefit of exposing the capability to the guest. If the Host enables ATS, the guest doesn't need to take any further action to benefit from the improved caching. If the host doesn't enable it, he won't issue invalidation either, so allowing the guest to enable it is unsafe. Thanks, Ilya -- To unsubscribe from this list: send the line "unsubscribe linux-pci" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
