[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <87zifo8wof.fsf@vitty.brq.redhat.com>
Date: Mon, 10 Apr 2017 11:00:00 +0200
From: Vitaly Kuznetsov <vkuznets@...hat.com>
To: Jork Loeser <Jork.Loeser@...rosoft.com>
Cc: "devel\@linuxdriverproject.org" <devel@...uxdriverproject.org>,
"x86\@kernel.org" <x86@...nel.org>,
"linux-kernel\@vger.kernel.org" <linux-kernel@...r.kernel.org>,
"KY Srinivasan" <kys@...rosoft.com>,
Haiyang Zhang <haiyangz@...rosoft.com>,
Stephen Hemminger <sthemmin@...rosoft.com>,
Thomas Gleixner <tglx@...utronix.de>,
Ingo Molnar <mingo@...hat.com>,
"H. Peter Anvin" <hpa@...or.com>,
Steven Rostedt <rostedt@...dmis.org>
Subject: Re: [PATCH 4/7] x86/hyperv: implement rep hypercalls
Jork Loeser <Jork.Loeser@...rosoft.com> writes:
>> -----Original Message-----
>> From: Vitaly Kuznetsov [mailto:vkuznets@...hat.com]
>> Sent: Friday, April 7, 2017 04:27
>> To: devel@...uxdriverproject.org; x86@...nel.org
>> Cc: linux-kernel@...r.kernel.org; KY Srinivasan <kys@...rosoft.com>;
>> Haiyang Zhang <haiyangz@...rosoft.com>; Stephen Hemminger
>> <sthemmin@...rosoft.com>; Thomas Gleixner <tglx@...utronix.de>; Ingo
>> Molnar <mingo@...hat.com>; H. Peter Anvin <hpa@...or.com>; Steven
>> Rostedt <rostedt@...dmis.org>; Jork Loeser <Jork.Loeser@...rosoft.com>
>> Subject: [PATCH 4/7] x86/hyperv: implement rep hypercalls
>
>> diff --git a/arch/x86/include/asm/mshyperv.h
>> b/arch/x86/include/asm/mshyperv.h index 9a5f58b..a2c996b 100644
>> --- a/arch/x86/include/asm/mshyperv.h
>> +++ b/arch/x86/include/asm/mshyperv.h
>> @@ -4,6 +4,7 @@
>> #include <linux/types.h>
>> #include <linux/interrupt.h>
>> #include <linux/clocksource.h>
>> +#include <linux/nmi.h>
>> #include <asm/hyperv.h>
>>
>> /*
>> @@ -253,6 +254,26 @@ static inline u64 hv_do_fast_hypercall8(u16 code,
>> u64 input1) #endif }
>>
>> +static inline u64 hv_do_rep_hypercall(u16 code, u16 rep_count, void
>> *input,
>> + void *output)
>> +{
>> + union hv_hypercall_input hc_input = { .code = code,
>> + .rep_count = rep_count};
>
> Is there a way to statically verify the re-count not to exceed 12 bits? Could a dynamic check be justified? Perhaps a function comment?
I'd like to avoid dynamic checks here to keep this as fast as
possible. Static check is probably not an option as even the only user
we have now calculates this parameter dynamically. I'll add a comment to
the function, thanks!
--
Vitaly
Powered by blists - more mailing lists