This patch maps RMRR in intel_iommu_add_device() if the device has RMRR; move domain_context_mapping() to be in front of list_move() in reassign_device_ownership(). Currently, hypervisor sets up devices and RMRR for dom0, and dom0 also adds devices for itself via hypercall. This is obviously duplicate. In order to allow old dom0 kernels to work with iommu-capable platforms, maybe it cannot be removed now. But what time is suitable to solve it? Signed-off-by: Weidong Han <weidong.han@intel.com> _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Espen Skoglund
2008-Jul-25 13:12 UTC
Re: [Xen-devel] [PATCH 1/4] Various VT-d code cleanup
[Weidong Han]> This patch maps RMRR in intel_iommu_add_device() if the device has > RMRR; move domain_context_mapping() to be in front of list_move() in > reassign_device_ownership().> Currently, hypervisor sets up devices and RMRR for dom0, and dom0 > also adds devices for itself via hypercall. This is obviously > duplicate. In order to allow old dom0 kernels to work with > iommu-capable platforms, maybe it cannot be removed now. But what > time is suitable to solve it?I find this whole RMRR device story higly suspicious. I would have expected that an RMRR device being unmapped from the context entry would (obviously) stop to function. Having it hang the whole system is rather more serious than anticipated --- in particular if one performs an FLR on the device before unmapping it. Even worse, given the "always set to non-present and flush IOTLB before reassigning" requirement stated in another thread, one can never reassign an RMRR device since it involves unmapping it first; which in turn could cause the system to hang. eSk _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel