On 23/11/2018 14:28, Andrew Cooper wrote: > On 23/11/2018 13:25, Juergen Gross wrote: >> In debug builds the hypervisor will deliberately clobber processed >> elements of the multicall structure. In order to ease diagnostic data >> printout in the affected guest only clobber elements which didn't >> return an error. >> >> Signed-off-by: Juergen Gross <jgr...@suse.com> >> --- >> xen/common/multicall.c | 1 + >> 1 file changed, 1 insertion(+) >> >> diff --git a/xen/common/multicall.c b/xen/common/multicall.c >> index 5a199ebf8f..48622619ce 100644 >> --- a/xen/common/multicall.c >> +++ b/xen/common/multicall.c >> @@ -74,6 +74,7 @@ do_multicall( >> ASSERT_NOT_IN_ATOMIC(); >> >> #ifndef NDEBUG >> + if ( (long)mcs->call.result >= 0 ) > > While I appreciate your point and agree that this is good in principle, > the failure condition is per-hypercall, and not always negative.
In theory you may be right. OTOH the related code in the Linux kernel checks exactly what I am aiming at: In case any multicall element has a negative result this is regarded to be an error and a WARN is issued. A negative return value of the multicall hypercall is regarded to be a BUG(). > I've tried playing a similar game before and couldn't come up with a > viable option. In the end the result will be better than today, even if the heuristic for detecting an error in a multicall entry might be not optimal. Juergen _______________________________________________ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
