Re: [Xen-devel] [PATCH v5 5/7] VT-d: Refactor iommu_ops .map_page() and unmap_page()

["Xu, Quan" <quan.xu@xxxxxxxxx>]

> On February 17, 2016 10:23pm, <JBeulich@xxxxxxxx> wrote:
> >>> On 05.02.16 at 11:18, <quan.xu@xxxxxxxxx> wrote:
> > to pass down a flag indicating whether the lock is being held, and
> > check the way up the call trees.
> 
> Same comments as on the previous patch; most of the changes outside of
> xen/drivers/passthrough/ seem to be avoidable here.
> 

(VT-d RMRR / P2M EPT)

Jan,
   When I fix the VT-d RMRR related code 
     1. $... iommu_map_page()/iommu_unmap_page() 
--p2m->set_entry()--p2m_set_entry()--set_identity_p2m_entry() / 
clear_identity_p2m_entry()-- rmrr_identity_mapping()--... ,
     2. $... iommu_pte_flush() 
--p2m->set_entry()--p2m_set_entry()--set_identity_p2m_entry() / 
clear_identity_p2m_entry()-- rmrr_identity_mapping()--... ,

 I found that the pcidevs_lock is being held for p2m_set_entry(). It is a 
corner case which is _not_ fix in previous patch set. As similar, I think I 
need to add p2m_set_entry_locked() to pass down a flag indicating
 whether the pcidevs_lock is being held. Right?

BTW, just a quick question, what's the difference between p2m-ept.c and 
p2m-pt.c ? Thanks.


Quan

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel