On Tue, May 31, 2016 at 10:26:29PM -0400, David Kershner wrote:
> From: Erik Arfvidson <erik.arfvidson@xxxxxxxxxx>
>
> This patch changes the vague -1 return values to -EPERM.
> This operation is not supported is a good alternative
> to -1 because the return is basically telling the caller
> that the processor doesn't support vmcall operations.
>
> Signed-off-by: Erik Arfvidson <erik.arfvidson@xxxxxxxxxx>
> Signed-off-by: David Kershner <david.kershner@xxxxxxxxxx>
> Reviewed-by: Tim Sell <Timothy.Sell@xxxxxxxxxx>
> ---
> drivers/staging/unisys/visorbus/iovmcall_gnuc.h | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/staging/unisys/visorbus/iovmcall_gnuc.h b/drivers/staging/unisys/visorbus/iovmcall_gnuc.h
> index b08b6ec..98ea7f3 100644
> --- a/drivers/staging/unisys/visorbus/iovmcall_gnuc.h
> +++ b/drivers/staging/unisys/visorbus/iovmcall_gnuc.h
> @@ -22,7 +22,7 @@ __unisys_vmcall_gnuc(unsigned long tuple, unsigned long reg_ebx,
>
> cpuid(0x00000001, &cpuid_eax, &cpuid_ebx, &cpuid_ecx, &cpuid_edx);
> if (!(cpuid_ecx & 0x80000000))
> - return -1;
> + return -EPERM;
>
> __asm__ __volatile__(".byte 0x00f, 0x001, 0x0c1" : "=a"(result) :
> "a"(tuple), "b"(reg_ebx), "c"(reg_ecx));
> @@ -40,7 +40,7 @@ __unisys_extended_vmcall_gnuc(unsigned long long tuple,
>
> cpuid(0x00000001, &cpuid_eax, &cpuid_ebx, &cpuid_ecx, &cpuid_edx);
> if (!(cpuid_ecx & 0x80000000))
> - return -1;
> + return -EPERM;
>
> __asm__ __volatile__(".byte 0x00f, 0x001, 0x0c1" : "=a"(result) :
> "a"(tuple), "b"(reg_ebx), "c"(reg_ecx), "d"(reg_edx));
> --
> 1.9.1
>
This gets properly checked as far as return codes go for the most part, which is
good, but in the case of an issuing of the
VMCALL_QUERY_GUEST_VIRTUAL_TIME_OFFSET ioctl, the return code is simply copied
into a user space buffer. That might be expected if -1 is used as an error
condition marker, but I would check before you assume that a user space caller
will handle -EINVAL properly there.
_______________________________________________
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxx
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
