lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Mon, 10 Apr 2017 10:46:30 +0200
From:   Vitaly Kuznetsov <vkuznets@...hat.com>
To:     KY Srinivasan <kys@...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>,
        "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: Re: [PATCH 2/7] x86/hyper-v: fast hypercall implementation

KY Srinivasan <kys@...rosoft.com> writes:

>> -----Original Message-----
>> From: Vitaly Kuznetsov [mailto:vkuznets@...hat.com]
>> Sent: Friday, April 7, 2017 4:27 AM
>> 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 2/7] x86/hyper-v: fast hypercall implementation
>> 
>> Hyper-V supports 'fast' hypercalls when all parameters are passed through
>> registers. Implement an inline version of a simpliest of these calls:
>> hypercall with one 8-byte input and no output.
>> 
>> Proper hypercall input interface (struct hv_hypercall_input) definition is
>> added as well.
>> 
>> Signed-off-by: Vitaly Kuznetsov <vkuznets@...hat.com>
>> ---
>>  arch/x86/include/asm/mshyperv.h    | 37
>> +++++++++++++++++++++++++++++++++++++
>>  arch/x86/include/uapi/asm/hyperv.h | 19 +++++++++++++++++++
>>  2 files changed, 56 insertions(+)
>> 
>> diff --git a/arch/x86/include/asm/mshyperv.h
>> b/arch/x86/include/asm/mshyperv.h
>> index 331e834..9a5f58b 100644
>> --- a/arch/x86/include/asm/mshyperv.h
>> +++ b/arch/x86/include/asm/mshyperv.h
>> @@ -216,6 +216,43 @@ static inline u64 hv_do_hypercall(u64 control, void
>> *input, void *output)
>>  #endif /* !x86_64 */
>>  }
>> 
>> +/* Fast hypercall with 8 bytes of input and no output */
>> +static inline u64 hv_do_fast_hypercall8(u16 code, u64 input1)
>> +{
>> +	union hv_hypercall_input control = {0};
>
> Defining the hyper-call arguments on the stack can be problematic
> if CONFIG_VMAP_STACK is defined - since we are passing the guest
> physical address to the hypervisor, we cannot have the arguments
> straddle a page boundary.
> We have dealt with this issue currently by making sure the arguments are
> never on the stack via different means. Perhaps, we can allocate memory
> on a per-cpu basis that can be used for this purpose. In fact, this is what I have done
> for the   hv_post_message hypercall. We can just rename that page and use it in all
> hypercalls - we can just allocate two pages on a per-CPU basis for this purpose
> (for input and output parameters).

This is fast hypercall and not the normal one - we pass control to
register so we're fine here (and I'd actually expect the compiler to put
it to the propper register in the first place.


>> +
>> +	control.code = code;
>> +	control.fast = 1;
>> +#ifdef CONFIG_X86_64
>> +	{
>> +		u64 hv_status;
>> +
>> +		__asm__ __volatile__("call *%3"
>> +				     : "=a" (hv_status)
>> +				     : "c" (control.as_uint64), "d" (input1),
>> +				       "m" (hv_hypercall_pg)
>> +				     : "cc", "r8", "%r9", "%r10", "%r11");
>> +		return hv_status;
>> +	}
>> +#else
>> +	{
>> +		u32 hv_status_hi, hv_status_lo;
>> +
>> +		__asm__ __volatile__ ("call *%6"
>> +				      : "=d"(hv_status_hi),
>> +					"=a"(hv_status_lo) :
>> +					"d" (control.as_uint32_hi),
>> +					"a" (control.as_uint32_lo),
>> +					"c" ((u32)input1),
>> +					"b" ((u32)(input1 >> 32)),
>> +					"m" (hv_hypercall_pg)
>> +				      : "cc");
>> +
>> +		return hv_status_lo | ((u64)hv_status_hi << 32);
>> +	}
>> +#endif
>> +}
>> +
>>  void hyperv_init(void);
>>  void hyperv_report_panic(struct pt_regs *regs);
>>  bool hv_is_hypercall_page_setup(void);
>> diff --git a/arch/x86/include/uapi/asm/hyperv.h
>> b/arch/x86/include/uapi/asm/hyperv.h
>> index 432df4b..c87e900 100644
>> --- a/arch/x86/include/uapi/asm/hyperv.h
>> +++ b/arch/x86/include/uapi/asm/hyperv.h
>> @@ -256,6 +256,25 @@
>>  #define HV_PROCESSOR_POWER_STATE_C2		2
>>  #define HV_PROCESSOR_POWER_STATE_C3		3
>> 
>> +/* Hypercall interface */
>> +union hv_hypercall_input {
>> +	u64 as_uint64;
>> +	struct {
>> +		__u32 as_uint32_lo;
>> +		__u32 as_uint32_hi;
>> +	};
>> +	struct {
>> +		__u64 code:16;
>> +		__u64 fast:1;
>> +		__u64 varhead_size:10;
>> +		__u64 reserved1:5;
>> +		__u64 rep_count:12;
>> +		__u64 reserved2:4;
>> +		__u64 rep_start:12;
>> +		__u64 reserved3:4;
>> +	};
>> +};
>> +
>>  /* hypercall status code */
>>  #define HV_STATUS_SUCCESS			0
>>  #define HV_STATUS_INVALID_HYPERCALL_CODE	2
>> --
>> 2.9.3

-- 
  Vitaly

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ