[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] Re: Possible regression in "x86-64: reduce range spanned by 1:1 mapping and frame table indexes"
On Fri, Dec 11, 2009 at 10:16:36AM +0000, Jan Beulich wrote: > >>> Simon Horman <horms@xxxxxxxxxxxx> 11.12.09 02:39 >>> > >106705 sh: sh_page_fault__guest_2(): fast path mmio 0x000000000b8f9e > >106706 sh: sh_page_fault__guest_2(): d:v=1:0 va=0xf30000d8 err=2, rip=6f6 > >... > >106721 shdebug: make_fl1_shadow(): (f3000)=>118644 > >106722 sh: set_fl1_shadow_status(): gfn=f3000, type=00000002, smfn=118644 > >106723 shdebug: _sh_propagate(): demand write level 2 guest f30000e7 shadow > >0000000118644067 > >106724 sh: sh_page_fault__guest_2(): 3241: L > >106725 shdebug: _sh_propagate(): demand write level 1 guest f3000067 shadow > >00000000f0500037 > >106726 sh: sh_page_fault__guest_2(): 3263: M > >106727 shdebug: _sh_propagate(): prefetch level 1 guest f3001067 shadow > >00000000f0501037 > >... > >106770 sh: sh_page_fault__guest_2(): emulator failure, unshadowing mfn > >0xf0500 > >106771 sh: sh_remove_shadows(): d=1, v=0, gmfn=f0500 > > The thing is that calling sh_remove_shadows(), as it is implemented, is > invalid for mmio pages, as there's no guarantee that those would have > a struct page_info associated (and there never was such a guarantee, > with the patches referenced the likelihood just increased that this would > happen). > > A possible fix would seem to be to simply do nothing in > sh_remove_shadows() if !mfn_valid(gmfn), but me not really being > knowledgeable in shadow code means that this may be the entirely > wrong thing to do. Tim? That does seem to work :-) Tim seems to have a few other ideas too. _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxx http://lists.xensource.com/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |