Xen devel - Jul 2008 - [PATCH 1/4] Various VT-d code cleanup

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

[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