WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

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@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel

<Prev in Thread] Current Thread [Next in Thread>