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

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 16.04.15 at 11:28, <tim@xxxxxxx> wrote:
> At 22:35 +0100 on 11 Apr (1428791713), Andrew Cooper wrote:
>> I am not certain that it is the correct way to fix the issue, nor that
>> the ioreq server code is the only way to trigger it.  There are several
>> ways to shoot a gfn mapping from the guests physmap.
>> 
>> At least we now understand why it happens.  I will defer to others CC'd
>> on this thread for their opinions in the matter.
> 
> The patch semes like a pretty good check to me, though I'm not
> convinced it's race-free.  At the least I'd cache the m2p lookup so we
> use the same value for the checks and the map_page() call. 

Did you have a chance to look at the patch Sander meanwhile
successfully tested [1]? I'm trying to understand where you see
possible races here, and hence whether anything else needs to
be done to that patch before formally submitting it. 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.

Thanks, Jan

[1] http://lists.xenproject.org/archives/html/xen-devel/2015-04/msg02253.html

> And IMO update_paging_mode() ought to log and reject bogus GFNs as
> well.
> 
> Cheers,
> 
> Tim.




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