>>> On 05.05.15 at 17:17, <t...@xen.org> wrote: > At 16:10 +0100 on 05 May (1430842206), Jan Beulich wrote: >> From what I >> can tell (and assuming other code works correctly) the fact that >> arch_iommu_populate_page_table() sets d->need_iommu to -1 >> first thing should make sure that any subsequent changes to the >> p2m get propagated to IOMMU code for setting up respective >> mappings. > > Yes, but might they then be overridden by the previous mapping when > this new code calls map_page()?
Ah, I see now. > This seems like a case where we should be using get_gfn()/put_gfn(). Yes - provided these may be called at all with the page_alloc_lock held. IOW - is there lock ordering defined between this one and the various mm locks? Also, if doing so, would I then need to check the result of the inverse (p2m) translation after having done get_gfn() to make sure this is still the MFN I'm after? If so, and if it ends up being a different one, I'd have to retry and presumably somehow limit the number of retries... Jan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
