WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

Re: [Xen-devel] Re: Possible regression in "x86-64: reduce range spanned

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

<Prev in Thread] Current Thread [Next in Thread>