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

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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.