From mboxrd@z Thu Jan 1 00:00:00 1970 From: David Vrabel Subject: Re: [PATCHv2 0/2] xen/privcmd: support for paged-out frames Date: Thu, 30 Aug 2012 11:09:13 +0100 Message-ID: <503F3BC9.6020100@citrix.com> References: <1346246116-29999-1-git-send-email-david.vrabel@citrix.com> <1346257402.20019.9.camel@zakaz.uk.xensource.com> <503E49BE.7080704@citrix.com> <1346263520.6655.4.camel@dagon.hellion.org.uk> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <1346263520.6655.4.camel@dagon.hellion.org.uk> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Ian Campbell Cc: Andres Lagar-Cavilla , "xen-devel@lists.xensource.com" , Konrad Rzeszutek Wilk List-Id: xen-devel@lists.xenproject.org On 29/08/12 19:05, Ian Campbell wrote: > On Wed, 2012-08-29 at 17:56 +0100, David Vrabel wrote: >> On 29/08/12 17:23, Ian Campbell wrote: >>> On Wed, 2012-08-29 at 14:15 +0100, David Vrabel wrote: >>>> This series is a straight forward-port of some functionality from >>>> classic kernels to support Xen hosts that do paging of guests. >>>> >>>> This isn't functionality the XenServer makes use of so I've not tested >>>> these with paging in use. >>>> >>>> Changes since v1: >>>> >>>> - Don't change PRIVCMD_MMAPBATCH (except to #define a constant for the >>>> error). It's broken and not really fixable sensibly and libxc will >>>> use V2 if it is available. >>>> - Return -ENOENT if all failures were -ENOENT. >>> >>> Is this behaviour a requirement from something? >> >> It's the behaviour libxc is expecting. It doesn't retry unless errno == >> ENOENT. > > Surely if that is the case you must return -ENOENT if *any* failure was > -ENOENT? That seems to be what the linux-2.6.18-xen.hg implementation > does. Yes. libxc will subsequently fail the whole map call is any frame errors without ENOENT so if someone was to propose a V3 it may be useful to return a different error code for other errors. >>> Usually hypercalls of this type return a global error only if something >>> went wrong with the general mechanics of the hypercall (e.g. faults >>> reading arguments etc) and leave reporting of the individual failures of >>> subops to the op specific field, even if all the subops fail in the same >>> way. >> >> I didn't design this interface... > > The interface you described doesn't make any sense... I don't entirely agree. There are three types of result: success, retryable errors, and fatal errors. It's not nonsensical to return different error codes for these. Regardless, it's not what the original implementation does so I'll fix rework the patch. David