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

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



Tuesday, April 21, 2015, 10:11:07 AM, you wrote:

>>>> On 20.04.15 at 20:50, <linux@xxxxxxxxxxxxxx> wrote:
>> Monday, April 20, 2015, 6:11:42 PM, you wrote:
>>>>>> On 16.04.15 at 11:28, <tim@xxxxxxx> wrote:
>>>> At 22:35 +0100 on 11 Apr (1428791713), Andrew Cooper wrote:
>>>>> 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. 
>>>> 
>>>> And IMO update_paging_mode() ought to log and reject bogus GFNs as
>>>> well.
>> 
>>> could you give the patch below a try, namely also in the context
>>> of seeing again the issue originally fixed by Andrew's initial patch?
>>> Please make sure you try a debug build and you have
>>> "iommu=debug" on the Xen command line.
>> 
>> I'm running with it now, have seen no issues so far !

> Interesting - didn't you say that as a side effect of Andrew's patch
> you saw massive log spam?

> Jan

If you mean these:

(XEN) [2015-04-12 14:55:20.226] p2m.c:884:d0v0 gfn_to_mfn failed! 
gfn=ffffffff001ed type:4
(XEN) [2015-04-12 14:55:20.226] p2m.c:884:d0v0 gfn_to_mfn failed! 
gfn=ffffffff001ee type:4
(XEN) [2015-04-12 14:55:20.226] p2m.c:884:d0v0 gfn_to_mfn failed! 
gfn=ffffffff001ef type:4
(XEN) [2015-04-12 14:55:20.226] p2m.c:884:d0v0 gfn_to_mfn failed! 
gfn=ffffffff001f0 type:4
(XEN) [2015-04-12 14:55:20.226] p2m.c:884:d0v0 gfn_to_mfn failed! 
gfn=ffffffff001f1 type:4
(XEN) [2015-04-12 14:55:20.226] p2m.c:884:d0v0 gfn_to_mfn failed! 
gfn=ffffffff001f2 type:4
(XEN) [2015-04-12 14:55:20.226] p2m.c:884:d0v0 gfn_to_mfn failed! 
gfn=ffffffff001f3 type:4
(XEN) [2015-04-12 14:55:20.226] p2m.c:884:d0v0 gfn_to_mfn failed! 
gfn=ffffffff001f4 type:4
(XEN) [2015-04-12 14:55:20.226] p2m.c:884:d0v0 gfn_to_mfn failed! 
gfn=ffffffff001f5 type:4
(XEN) [2015-04-12 14:55:20.226] p2m.c:884:d0v0 gfn_to_mfn failed! 
gfn=ffffffff001f6 type:4

Those were actually due to Konrad's kernel patch that was on the devel-4.1 
branch that has already been dropped. 
(commit 22d8a8938407cb1342af763e937fdf9ee8daf24a
 'xen/pciback: Don't disable PCI_COMMAND on PCI device reset.')

For the rest there is some extra log spam now, since the memory maps now are 
done 
in very small chunks (the hypercall continuation stuff working?):
(XEN) [2015-04-21 08:04:01.207] memory_map:add: dom20 gfn=ec780 mfn=cc780 nr=40
(XEN) [2015-04-21 08:04:01.209] memory_map:add: dom20 gfn=ec7c0 mfn=cc7c0 nr=40
(XEN) [2015-04-21 08:04:01.211] memory_map:add: dom20 gfn=ec800 mfn=cc800 nr=40
(XEN) [2015-04-21 08:04:01.214] memory_map:add: dom20 gfn=ec840 mfn=cc840 nr=40
(XEN) [2015-04-21 08:04:01.215] memory_map:add: dom20 gfn=ec880 mfn=cc880 nr=40
(XEN) [2015-04-21 08:04:01.216] memory_map:add: dom20 gfn=ec8c0 mfn=cc8c0 nr=40
(XEN) [2015-04-21 08:04:01.219] memory_map:add: dom20 gfn=ec900 mfn=cc900 nr=40
(XEN) [2015-04-21 08:04:01.221] memory_map:add: dom20 gfn=ec940 mfn=cc940 nr=40
(XEN) [2015-04-21 08:04:01.223] memory_map:add: dom20 gfn=ec980 mfn=cc980 nr=40
(XEN) [2015-04-21 08:04:01.225] memory_map:add: dom20 gfn=ec9c0 mfn=cc9c0 nr=40
(XEN) [2015-04-21 08:04:01.228] memory_map:add: dom20 gfn=eca00 mfn=cca00 nr=40
(XEN) [2015-04-21 08:04:01.229] memory_map:add: dom20 gfn=eca40 mfn=cca40 nr=40
(XEN) [2015-04-21 08:04:01.232] memory_map:add: dom20 gfn=eca80 mfn=cca80 nr=40
(XEN) [2015-04-21 08:04:01.234] memory_map:add: dom20 gfn=ecac0 mfn=ccac0 nr=40
(XEN) [2015-04-21 08:04:01.236] memory_map:add: dom20 gfn=ecb00 mfn=ccb00 nr=40
(XEN) [2015-04-21 08:04:01.238] memory_map:add: dom20 gfn=ecb40 mfn=ccb40 nr=40
(XEN) [2015-04-21 08:04:01.240] memory_map:add: dom20 gfn=ecb80 mfn=ccb80 nr=40
(XEN) [2015-04-21 08:04:01.242] memory_map:add: dom20 gfn=ecbc0 mfn=ccbc0 nr=40
(XEN) [2015-04-21 08:04:01.244] memory_map:add: dom20 gfn=ecc00 mfn=ccc00 nr=40
(XEN) [2015-04-21 08:04:01.246] memory_map:add: dom20 gfn=ecc40 mfn=ccc40 nr=40
(XEN) [2015-04-21 08:04:01.248] memory_map:add: dom20 gfn=ecc80 mfn=ccc80 nr=40
(XEN) [2015-04-21 08:04:01.250] memory_map:add: dom20 gfn=eccc0 mfn=cccc0 nr=40
(XEN) [2015-04-21 08:04:01.252] memory_map:add: dom20 gfn=ecd00 mfn=ccd00 nr=40
(XEN) [2015-04-21 08:04:01.254] memory_map:add: dom20 gfn=ecd40 mfn=ccd40 nr=40
(XEN) [2015-04-21 08:04:01.257] memory_map:add: dom20 gfn=ecd80 mfn=ccd80 nr=40
(XEN) [2015-04-21 08:04:01.259] memory_map:add: dom20 gfn=ecdc0 mfn=ccdc0 nr=40
(XEN) [2015-04-21 08:04:01.261] memory_map:add: dom20 gfn=ece00 mfn=cce00 nr=40
(XEN) [2015-04-21 08:04:01.263] memory_map:add: dom20 gfn=ece40 mfn=cce40 nr=40
(XEN) [2015-04-21 08:04:01.266] memory_map:add: dom20 gfn=ece80 mfn=cce80 nr=40
(XEN) [2015-04-21 08:04:01.267] memory_map:add: dom20 gfn=ecec0 mfn=ccec0 nr=40
(XEN) [2015-04-21 08:04:01.269] memory_map:add: dom20 gfn=ecf00 mfn=ccf00 nr=40
(XEN) [2015-04-21 08:04:01.272] memory_map:add: dom20 gfn=ecf40 mfn=ccf40 nr=40
(XEN) [2015-04-21 08:04:01.274] memory_map:add: dom20 gfn=ecf80 mfn=ccf80 nr=40
(XEN) [2015-04-21 08:04:01.276] memory_map:add: dom20 gfn=ecfc0 mfn=ccfc0 nr=40
(XEN) [2015-04-21 08:04:01.279] memory_map:add: dom20 gfn=ed000 mfn=cd000 nr=40
(XEN) [2015-04-21 08:04:01.281] memory_map:add: dom20 gfn=ed040 mfn=cd040 nr=40
(XEN) [2015-04-21 08:04:01.284] memory_map:add: dom20 gfn=ed080 mfn=cd080 nr=40
(XEN) [2015-04-21 08:04:01.285] memory_map:add: dom20 gfn=ed0c0 mfn=cd0c0 nr=40
(XEN) [2015-04-21 08:04:01.287] memory_map:add: dom20 gfn=ed100 mfn=cd100 nr=40
(XEN) [2015-04-21 08:04:01.290] memory_map:add: dom20 gfn=ed140 mfn=cd140 nr=40
 etc. etc.

Don't know if that makes much sense anymore (unless specifically enabled if you 
want such detail .. and the whole range with perhaps a start and finish message 
is not enough)

--
Sander


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


 


Rackspace

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