Re: [PATCH] x86/shadow: account for ioreq server pages before complaining about not found mapping

[Wei Liu <wei.liu2@citrix.com>]

On Fri, Apr 29, 2016 at 02:13:35AM -0600, Jan Beulich wrote:
> prepare_ring_for_helper(), just like share_xen_page_with_guest(),
> takes a write reference on the page, and hence should similarly be
> accounted for when determining whether to log a complaint.
> 
> This requires using recursive locking for the ioreq server lock, as the
> offending invocation of sh_remove_all_mappings() is down the call stack
> from hvm_set_ioreq_server_state(). (While not strictly needed to be
> done in all other instances too, convert all of them for consistency.)
> 
> At once improve the usefulness of the shadow error message: Log all
> values involved in triggering it as well as the GFN (to aid
> understanding which guest page it is that there is a problem with - in
> cases like the one here the GFN is invariant across invocations, while
> the MFN obviously can [and will] vary).
> 
> Signed-off-by: Jan Beulich <jbeulich@suse.com>
> 

Release-acked-by: Wei Liu <wei.liu2@citrix.com>

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