https://community.intel.com/t5/Software-Archive/VTd-Invalidations/m-p/835629#M6307 <P>Would anybody have a pointer to some documentation about how VTd memory mappings are used in current VMMs? It seems most examples imply that a VTd domain is started as each guest is started and remains basically static for the life of the guest. Thus, I/O devices won't have to deal with frequent VTd invalidations since the domains themselves remain fairly persistent.<BR /><BR />However, one can imagine a system that seeks to really limit devices to the absolute minimum access rights. Such a system would frequently be updating permissions and revoking them in response to application behavior. This would lead to frequent VTd invalidations.Of course, any VTd caching I/O devices were trying to do would be fairly useless as they would have to flush all the time.While such a system seems like it would be fairly inefficient, it's not beyond the realm of possibility.<BR /><BR />Does anybody know of a VMM that does this or of some published documentation that says VMMs really don't (or shouldn't) do this?</P> Fri, 20 Aug 2010 18:18:09 GMT Anthony_B_Intel 2010-08-20T18:18:09Z https://community.intel.com/t5/Software-Archive/VTd-Invalidations/m-p/835629#M6307 <P>Would anybody have a pointer to some documentation about how VTd memory mappings are used in current VMMs? It seems most examples imply that a VTd domain is started as each guest is started and remains basically static for the life of the guest. Thus, I/O devices won't have to deal with frequent VTd invalidations since the domains themselves remain fairly persistent.<BR /><BR />However, one can imagine a system that seeks to really limit devices to the absolute minimum access rights. Such a system would frequently be updating permissions and revoking them in response to application behavior. This would lead to frequent VTd invalidations.Of course, any VTd caching I/O devices were trying to do would be fairly useless as they would have to flush all the time.While such a system seems like it would be fairly inefficient, it's not beyond the realm of possibility.<BR /><BR />Does anybody know of a VMM that does this or of some published documentation that says VMMs really don't (or shouldn't) do this?</P> Fri, 20 Aug 2010 18:18:09 GMT https://community.intel.com/t5/Software-Archive/VTd-Invalidations/m-p/835629#M6307 Anthony_B_Intel 2010-08-20T18:18:09Z https://community.intel.com/t5/Software-Archive/VTd-Invalidations/m-p/835630#M6308 The architecture specifications document probably has the answer to your question:<BR /><A href="http://download.intel.com/technology/computing/vptech/Intel_VT_for_Direct_IO.pdf" title="VT-D architecture specifications">VT-D Architecture Specifications</A><BR /><BR />In general a Virtual Machine that has a PCI device directly attached to it (i.e. in passthrough mode, which requires the VT-D chipset support) has to have its memory reserved (this is the ESX terminology, I am sure Xen and other VMMs have similar terminology). I think this is their solution to the complication you identified.<BR /><BR />There are some chipset structures that deal with MMIO invalidations and there arenewer structures added to support the VT-D feature (like an IOTLB cache). The document has a description of their functionality which might answer your question.<BR /><BR />If this doesn't address your question, and you can't find what you are looking for in the specs document, can you rephrase your question more precisely and I will do what I can to get you an answer. An example would be helpful as well. Mon, 23 Aug 2010 23:27:05 GMT https://community.intel.com/t5/Software-Archive/VTd-Invalidations/m-p/835630#M6308 Hussam_Mousa__Intel_ 2010-08-23T23:27:05Z