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
|
Home