Re: [Xen-devel] Xen-unstable-staging: Xen BUG at iommu_map.c:455

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 05.05.15 at 17:17, <tim@xxxxxxx> 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@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel