From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jeremy Fitzhardinge Subject: Re: return value checking on multicalls Date: Wed, 14 Mar 2007 09:45:12 -0700 Message-ID: <45F82698.2050203@goop.org> References: <45F828EB.76E4.0078.0@novell.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <45F828EB.76E4.0078.0@novell.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Jan Beulich Cc: xen-devel@lists.xensource.com List-Id: xen-devel@lists.xenproject.org Jan Beulich wrote: > Many places currently don't even check HYPERVISOR_multicall()'s return > value, not to speak of checking the individual status codes. Would it be > acceptable to add an argument to this function to request to either fold > all status values into a global success code, or to force BUG_ON() each > individual status. Or should I rather add a new function with described > behavior? Or are there other suggestions? > In the xen-pvops tree I made a general-purpose hypercall batching mechanism, so that there's only one place which needs to check the multicall return. Its interface is: /* Multicalls */ struct multicall_space { struct multicall_entry *mc; void *args; }; /* Allocate room for a multicall and its args */ struct multicall_space xen_mc_entry(size_t args); /* Flush all pending multicalls */ void xen_mc_flush(void); /* Issue a multicall if we're not in lazy mode */ static inline void xen_mc_issue(void) { if (xen_get_lazy_mode() == PARAVIRT_LAZY_NONE) xen_mc_flush(); } xen_mc_flush() just BUGs if either the multicall hypercall itself fails, or any of the constituent hypercalls. J