From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from linux.microsoft.com (linux.microsoft.com [13.77.154.182]) by smtp.subspace.kernel.org (Postfix) with ESMTP id D229F1A23A9; Wed, 8 Jan 2025 23:04:59 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=13.77.154.182 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1736377501; cv=none; b=sqnsCwh1u6PVAG28j1ockKpfND+Ls4QlzUiiF8cO0wGic5Yaq068uPGU+aN248sN686EkUYqPfCtpPNEIbHKilScF4yMvyUdDB/OiC/rSRjw5utqoo19YruLTUww464AcAvCgDgzI6jn9YQG0GzDFrP5iIJccBO1IApZnJ55+jg= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1736377501; c=relaxed/simple; bh=EyiV/BvijB2ldfc3jrej22LAh7SPUIzCf1/PhGUQdrw=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=LIGm4DwFx7IftMQGTIuENPaPO68aBRmVdZqzVbrRJJHoF45BDqcVsBBaY70lx1+0qyZgIOeBXORB8r7SVzuqSGOO47fTP+aTO1CQZVcGnxePT5SYowctjyMoytQK+mJMQ3patnE0R0HNYb7uWtino/10kUSIKjB/i8RidvY340A= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.microsoft.com; spf=pass smtp.mailfrom=linux.microsoft.com; dkim=pass (1024-bit key) header.d=linux.microsoft.com header.i=@linux.microsoft.com header.b=pFMHNTaH; arc=none smtp.client-ip=13.77.154.182 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.microsoft.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linux.microsoft.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linux.microsoft.com header.i=@linux.microsoft.com header.b="pFMHNTaH" Received: from [10.137.184.60] (unknown [131.107.160.188]) by linux.microsoft.com (Postfix) with ESMTPSA id 17F14203E3AB; Wed, 8 Jan 2025 15:04:59 -0800 (PST) DKIM-Filter: OpenDKIM Filter v2.11.0 linux.microsoft.com 17F14203E3AB DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.microsoft.com; s=default; t=1736377499; bh=2S3Lexcslva6gIMXcBiHhJtUCoDBIa1gywieybOXNZY=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=pFMHNTaHkJDiXk3DU2mwoRAK5WpnYNAZC/DiN8UIAG6qUqSZ4qj2SZ5uhfvVN5Pdr wYvsfqGHWnRmU7aQNsAXHcMD8c4dA/88pR+1GeEBvnWgLkZiIYCbC1TJE1OFpbRrI+ f2Q39OFttFkLeMJkjvjr/a43KGQb9jXgxyfjnDPQ= Message-ID: <7e7499c1-ecbb-4bb2-81f5-d34c541103e6@linux.microsoft.com> Date: Wed, 8 Jan 2025 15:04:59 -0800 Precedence: bulk X-Mailing-List: linux-hyperv@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v5 3/5] hyperv: Enable the hypercall output page for the VTL mode To: Stanislav Kinsburskii Cc: hpa@zytor.com, kys@microsoft.com, bp@alien8.de, dave.hansen@linux.intel.com, decui@microsoft.com, eahariha@linux.microsoft.com, haiyangz@microsoft.com, mingo@redhat.com, mhklinux@outlook.com, nunodasneves@linux.microsoft.com, tglx@linutronix.de, tiala@microsoft.com, wei.liu@kernel.org, linux-hyperv@vger.kernel.org, linux-kernel@vger.kernel.org, x86@kernel.org, apais@microsoft.com, benhill@microsoft.com, ssengar@microsoft.com, sunilmut@microsoft.com, vdso@hexbites.dev References: <20250103192002.GA22059@skinsburskii.> <24594814-6b31-4dc9-83c3-2bafbd14e819@linux.microsoft.com> <20250106171114.GA18270@skinsburskii.> <20250106193248.GB18346@skinsburskii.> <3c90bc0f-be28-4f10-8057-be5e780c5a24@linux.microsoft.com> <20250107191848.GA24369@skinsburskii.> <17dfb71a-119c-4906-bc22-4f65fb28676b@linux.microsoft.com> <20250108191707.GA120@skinsburskii.> <95de0e7f-fb30-487e-820f-39d4e8c141cb@linux.microsoft.com> <20250108221918.GA2774@skinsburskii.> Content-Language: en-US From: Roman Kisel In-Reply-To: <20250108221918.GA2774@skinsburskii.> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 1/8/2025 2:19 PM, Stanislav Kinsburskii wrote: > On Wed, Jan 08, 2025 at 12:37:17PM -0800, Roman Kisel wrote: >> >> >> On 1/8/2025 11:17 AM, Stanislav Kinsburskii wrote: >>> On Tue, Jan 07, 2025 at 03:11:15PM -0800, Roman Kisel wrote: >> >> [...] >> >>>> >>>> Avoiding using the output hypercall page leads to something like[1] >>>> and it looks quite complicated although that's the bare bones, lots >>>> of notes. >>>> >>> >>> How is this related to the original discussion? >> >> I was looking for ways to eliminate what I perceived as the source of >> friction in the discussion -- allocating the hypercall output page. >> > > No, output page allocation is the current solution and it is fine. > The source of friction is allocation of this page under config option in > runtime. Same difference: the proposed fix makes sense in the hyperv-next tree. The change is a well-contained, the minimal, very economical code motion to fix the issue at hand, no risk to the tree was shown. Why predicate worthiness of the patch on a prototype LVBS kernel fork you've referred to being built outside of the LKML? When the time comes to take LVBS to the LKML, can easily rehash any of this due to the minuscule patch size, and until then it's just bets in what shape the future comes and when it does. Instead of betting and waiting, fixing the break is more beneficial so I've sent out v6. > > Thanks, > Stas > >>> My concern was about the piece allocating of the output page guarded by >>> the VTL config option.>> Thanks, >>> Stas >>> >>>> [1] >>>> >>>> /* >>>> * Fast extended hypercall with 20 bytes of input and 16 bytes of >>>> * output for getting a VP register. >>>> * >>>> * NOTES: >>>> * 1. The function is __init only atm, so the XMM context isn't >>>> * used by the user mode. >>>> * 2. X86_64 only. >>>> * 3. Fast extended hypercalls may use XMM0..XMM6, and XMM is >>>> * architerctural on X86_64 yet the support should be enabled >>>> * in the CR's. Here, need RDX, R8 and XMM0 for input and RDX, >>>> * R8 for output >>>> * 4. No provisions for TDX and SEV-SNP for the sake of simplicity >>>> * (the hypervisor cannot see the guest registers in the >>>> * confidential VM), would need to fallback. >>>> * 5. The robust implementation would need to check if fast extended >>>> * hypercalls are available by checking the synthehtic CPUID leaves. >>>> * A separate leaf indicates fast output support. >>>> * It _almost_ certainly has to be, unless somehow disabled, hard >>>> * to see why that would be needed. >>>> */ >>>> struct hv_u128 { >>>> u64 low_part; >>>> u64 high_part; >>>> } __packed; >>>> >>>> static __init u64 hv_vp_get_register_xfast(u32 reg_name, >>>> struct hv_u128 *value) >>>> { >>>> u64 control = HV_HYPERCALL_REP_COMP_1 | HVCALL_GET_VP_REGISTERS | >>>> HV_HYPERCALL_FAST_BIT; >>>> unsigned long flags; >>>> u64 hv_status; >>>> >>>> union { >>>> struct hv_get_vp_registers_input input; >>>> struct { >>>> u64 lo; >>>> u64 hi; >>>> } __packed as_u128; >>>> } hv_input; >>>> register u64 rdx asm("rdx"); >>>> register u64 r8 asm("r8"); >>>> register u64 r12 asm("r12"); >>>> >>>> local_irq_save(flags); >>>> >>>> hv_input.as_u128.lo = hv_input.as_u128.hi = 0; >>>> hv_input.input.header.partitionid = HV_PARTITION_ID_SELF; >>>> hv_input.input.header.vpindex = HV_VP_INDEX_SELF; >>>> hv_input.input.header.inputvtl = 0; >>>> >>>> rdx = hv_input.as_u128.lo; >>>> r8 = hv_input.as_u128.hi; >>>> r12 = reg_name; >>>> >>>> __asm__ __volatile__( >>>> "subq $16, %%rsp\n" >>>> "movups %%xmm0, 16(%%rsp)\n" >>>> "movd %%r12, %%xmm0\n" >>>> CALL_NOSPEC >>>> "movups 16(%%rsp), %%xmm0\n" >>>> "addq $16, %%rsp\n" >>>> : "=a" (hv_status), ASM_CALL_CONSTRAINT, >>>> "+c" (control), "+r" (rdx), "+r" (r8) >>>> : THUNK_TARGET(hv_hypercall_pg), "r"(r12) >>>> : "cc", "memory", "r9", "r10", "r11"); >>>> >>>> if (hv_result_success(hv_status)) { >>>> value->low_part = rdx; >>>> value->high_part = r8; >>>> } >>>> >>>> local_irq_restore(flags); >>>> return hv_status; >>>> } >>>> >>>> #if IS_ENABLED(CONFIG_HYPERV_VTL_MODE) >>>> u8 __init get_vtl(void) >>>> { >>>> struct hv_u128 reg_value; >>>> u64 ret = hv_vp_get_register_xfast(HV_REGISTER_VSM_VP_STATUS, ®_value); >>>> >>>> if (hv_result_success(ret)) { >>>> ret = reg_value.low_part & HV_VTL_MASK; >>>> } else { >>>> pr_err("Failed to get VTL(error: %lld) exiting...\n", ret); >>>> BUG(); >>>> } >>>> >>>> return ret; >>>> } >>>> #endif >>>> >>>>> >>>>> Thanks, >>>>> Stas >>>> >>>> -- >>>> Thank you, >>>> Roman >>>> >> >> -- >> Thank you, >> Roman >> -- Thank you, Roman