[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20180426213148.d5udlgzgbvtym25p@mwanda>
Date: Fri, 27 Apr 2018 00:31:49 +0300
From: Dan Carpenter <dan.carpenter@...cle.com>
To: kys@...rosoft.com
Cc: x86@...nel.org, gregkh@...uxfoundation.org,
linux-kernel@...r.kernel.org, devel@...uxdriverproject.org,
olaf@...fle.de, apw@...onical.com, jasowang@...hat.com,
tglx@...utronix.de, hpa@...or.com, sthemmin@...rosoft.com,
Michael.H.Kelley@...rosoft.com, vkuznets@...hat.com
Subject: Re: [PATCH 2/5] X86: Hyper-V: Enable IPI enlightenments
On Wed, Apr 25, 2018 at 11:12:47AM -0700, kys@...uxonhyperv.com wrote:
> +/*
> + * IPI implementation on Hyper-V.
> + */
> +
> +static int __send_ipi_mask(const struct cpumask *mask, int vector)
> +{
> + int cur_cpu, vcpu;
> + struct ipi_arg_non_ex **arg;
> + struct ipi_arg_non_ex *ipi_arg;
> + int ret = 1;
Not specifically related to this patch, but hv code sometimes returns 1
on error or U64_MAX. It's slightly magical. Maybe
HV_STATUS_INVALID_HYPERCALL_INPUT (3) would be more appropriate? Or we
could make a new more generic error code:
#define HV_STATUS_INVALID 1
regards,
dan carpenter
Powered by blists - more mailing lists