Re: [RFC PATCH 0/3] VFIO: Report IOMMU fault event to userspace

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 2/21/2017 11:18 PM, Lan Tianyu wrote:


As I understand your use case, particularly with PASID, you're trying
to enable the device to fault in mappings, which implies a dynamic
mapping use case.  Run a 10GBps NIC (or 40 or 100) in a viommu guest
_without_ using iommu=pt.  How close do you get to native performance?
How close can a virtio device get in the same configuration?  What is
the usefulness in extending type1 to support piommu faults if it
doesn't have worthwhile performance?

For SVM(called first level translation in VTD spec), it doesn't require
to shadow all first level page table. We just need to shadow gPASID
table pointer and put into extend context entry of pIOMMU. VTD hardware
can read guest first level page table directly because it supports
nested translation for request with PASID which helps to translate GPA
to HPA during reading guest page table. So for SVM, we don't need to go
through typ1 map/umap and dynamic map/umap will just happen in the guest.

For detail, please see Yi's [RFC Design Doc v2] Enable Shared Virtual
Memory feature
https://lists.gnu.org/archive/html/qemu-devel/2016-11/msg03617.html

BTW, current only Intel GPU supports request-with-PASID and device page request as far as I know,



[Index of Archives]     [KVM ARM]     [KVM ia64]     [KVM ppc]     [Virtualization Tools]     [Spice Development]     [Libvirt]     [Libvirt Users]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite Questions]     [Linux Kernel]     [Linux SCSI]     [XFree86]

  Powered by Linux