Re: [Xen-devel] Re: Possible regression in "x86-64: reduce range spanned by 1:1 mapping and frame table indexes"

["Jan Beulich" <JBeulich@xxxxxxxxxx>]

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

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel