Message ID | 1667537814-15939-1-git-send-email-ssengar@linux.microsoft.com |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a5d:6687:0:0:0:0:0 with SMTP id l7csp171900wru; Thu, 3 Nov 2022 21:57:54 -0700 (PDT) X-Google-Smtp-Source: AMsMyM4JDruxboPVu2ssRQKtdIWp+eOOIzNUSyAEFi21g7aIpO+3cVh6oS24P8AWOWiqIZfJA5wd X-Received: by 2002:a05:6402:e01:b0:442:dd7e:f49d with SMTP id h1-20020a0564020e0100b00442dd7ef49dmr33682927edh.355.1667537873873; Thu, 03 Nov 2022 21:57:53 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1667537873; cv=none; d=google.com; s=arc-20160816; b=nCOTTzCTHgf0qCFBwMhMhZbdvYHUdOfpz31btL84iGk78yn0siY86tD7FbGdVH96y/ /cvV3GRnZTlP/x1uFA+obWpvGm+oGn2su4AvtBum9Or3JabUZFE/RY5mB3UOf3kbCzHl e+hpRwQ7stpWNr8C5kUCBuA3s6zjVNODf1CxAMxIDcp9ADOZ2eqTdc2hwPJd4PQe/YBy 7iPDKNUWB2WFoiK7Sv4UXZY11B8sSJtCMkDbxQ85xUQNsulMpswSFwfqUeMrpMPIPYEb T3FAhtPlneg0tHRKHBu4D2ilG2eD1rFeMm73RcVcK+gSDpB3+roUbKoyYfEjE9SyoFrL w4hQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:message-id:date:subject:to:from:dkim-signature :dkim-filter; bh=7XcDCyS5Tt+1ZylW1x0vh/KEQR0FAI7fKUXuYluVgDA=; b=bc83gxzzLEveAWQJaLNA3jULUmDjP8KcnCDLiMwelfWzVvW2+VufWiVo0SA+Ch3e3i m7EaPv14q5PPMEo8qngUfCyGatESMbKe3diicOY8F5jMCPLzCyBxPEhH6hMGQdRkQWqa 8Jch9d8f04C8skkZ7cV+MYzLjfDE+T/u2570Ys/lYzMK/yXzRJBwFOOOwh5AHJvBOu26 d+w3nafUsNs24DrB9VQIMd1ExFmo1QaBvMPV5N+xUEWSP7gIbEQvlXLb3yiwzFdBd89q JInybPYnwFdBuphKCAzkjPrlh8evGUMtxmPbe6MR25Qy/N2xKoWslnCnEqIT3vcJfLVU 4E7w== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linux.microsoft.com header.s=default header.b=kmNEDKGc; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linux.microsoft.com Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id hc14-20020a170907168e00b0078d473448afsi4011253ejc.233.2022.11.03.21.57.30; Thu, 03 Nov 2022 21:57:53 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@linux.microsoft.com header.s=default header.b=kmNEDKGc; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linux.microsoft.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229884AbiKDE5A (ORCPT <rfc822;jimliu8233@gmail.com> + 99 others); Fri, 4 Nov 2022 00:57:00 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:35780 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229553AbiKDE46 (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Fri, 4 Nov 2022 00:56:58 -0400 Received: from linux.microsoft.com (linux.microsoft.com [13.77.154.182]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id 01353B78; Thu, 3 Nov 2022 21:56:57 -0700 (PDT) Received: from linuxonhyperv3.guj3yctzbm1etfxqx2vob5hsef.xx.internal.cloudapp.net (linux.microsoft.com [13.77.154.182]) by linux.microsoft.com (Postfix) with ESMTPSA id ADD3E205DA4A; Thu, 3 Nov 2022 21:56:57 -0700 (PDT) DKIM-Filter: OpenDKIM Filter v2.11.0 linux.microsoft.com ADD3E205DA4A DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.microsoft.com; s=default; t=1667537817; bh=7XcDCyS5Tt+1ZylW1x0vh/KEQR0FAI7fKUXuYluVgDA=; h=From:To:Subject:Date:From; b=kmNEDKGcWlB8WhPB8+MllKdG5GjRQXWJGxlZJ1bmdiFUS1HhPQxFwdQH/lMGo75Kd lVn7jtG4RxTG/We1t2yJyEFmUX93gxvn4cJt1tVHssVJfjDSVaTuwpPlkLbgDayDkJ dUaDbzTDA7koB79y/W5H2sbAVVNiNpS68ZmjuVEQ= From: Saurabh Sengar <ssengar@linux.microsoft.com> To: ssengar@microsoft.com, kys@microsoft.com, haiyangz@microsoft.com, wei.liu@kernel.org, decui@microsoft.com, ssengar@linux.microsoft.com, linux-hyperv@vger.kernel.org, linux-kernel@vger.kernel.org, mikelley@microsoft.com, tglx@linutronix.de, bp@alien8.de, dave.hansen@linux.intel.com, x86@kernel.org, hpa@zytor.com Subject: [PATCH] x86/Hyper-V: Expand definition of struct hv_vp_assist_page Date: Thu, 3 Nov 2022 21:56:54 -0700 Message-Id: <1667537814-15939-1-git-send-email-ssengar@linux.microsoft.com> X-Mailer: git-send-email 1.8.3.1 X-Spam-Status: No, score=-19.8 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,ENV_AND_HDR_SPF_MATCH,RCVD_IN_DNSWL_MED, SPF_HELO_PASS,SPF_PASS,USER_IN_DEF_DKIM_WL,USER_IN_DEF_SPF_WL autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1748540193187247338?= X-GMAIL-MSGID: =?utf-8?q?1748540193187247338?= |
Series |
x86/Hyper-V: Expand definition of struct hv_vp_assist_page
|
|
Commit Message
Saurabh Singh Sengar
Nov. 4, 2022, 4:56 a.m. UTC
The struct hv_vp_assist_page has 24 bytes which is defined as u64[3],
expand that to expose vtl_entry_reason, vtl_ret_x64rax and vtl_ret_x64rcx
field. vtl_entry_reason is updated by hypervisor for the entry reason as
to why the VTL was entered on the virtual processor.
Guest updates the vtl_ret_* fields to provide the register values to
restore on VTL return. The specific register values that are restored
which will be updated on vtl_ret_x64rax and vtl_ret_x64rcx.
Also added the missing fields for synthetic_time_unhalted_timer_expired,
virtualization_fault_information and intercept_message.
Signed-off-by: Saurabh Sengar <ssengar@linux.microsoft.com>
---
arch/x86/include/asm/hyperv-tlfs.h | 11 ++++++++++-
1 file changed, 10 insertions(+), 1 deletion(-)
Comments
On Thu, Nov 03, 2022 at 09:56:54PM -0700, Saurabh Sengar wrote: > The struct hv_vp_assist_page has 24 bytes which is defined as u64[3], > expand that to expose vtl_entry_reason, vtl_ret_x64rax and vtl_ret_x64rcx > field. vtl_entry_reason is updated by hypervisor for the entry reason as > to why the VTL was entered on the virtual processor. > Guest updates the vtl_ret_* fields to provide the register values to > restore on VTL return. The specific register values that are restored > which will be updated on vtl_ret_x64rax and vtl_ret_x64rcx. > Also added the missing fields for synthetic_time_unhalted_timer_expired, > virtualization_fault_information and intercept_message. > > Signed-off-by: Saurabh Sengar <ssengar@linux.microsoft.com> > --- > arch/x86/include/asm/hyperv-tlfs.h | 11 ++++++++++- > 1 file changed, 10 insertions(+), 1 deletion(-) > > diff --git a/arch/x86/include/asm/hyperv-tlfs.h b/arch/x86/include/asm/hyperv-tlfs.h > index f769b9db4630..b3d0f42853d2 100644 > --- a/arch/x86/include/asm/hyperv-tlfs.h > +++ b/arch/x86/include/asm/hyperv-tlfs.h > @@ -377,11 +377,20 @@ struct hv_nested_enlightenments_control { > struct hv_vp_assist_page { > __u32 apic_assist; > __u32 reserved1; > - __u64 vtl_control[3]; > + __u8 vtl_entry_reason; This is defined as an enum in the TLFS [1]. We should do the same. And since the TLFS defines it as an enum it is a 32 bit value and not a u8. > + __u8 vtl_reserved[7]; > + __u64 vtl_ret_x64rax; > + __u64 vtl_ret_x64rcx; The TLFS groups the above VTL related fields into a struct HV_VP_VTL_CONTROL. Any reason to not do the same? [1] https://learn.microsoft.com/en-us/virtualization/hyper-v-on-windows/tlfs/datatypes/hv_vp_vtl_control Thanks, Anirudh. > struct hv_nested_enlightenments_control nested_control; > __u8 enlighten_vmentry; > __u8 reserved2[7]; > __u64 current_nested_vmcs; > + __u8 synthetic_time_unhalted_timer_expired; > + __u8 reserved3[7]; > + __u8 virtualization_fault_information[40]; > + __u8 reserved4[8]; > + __u8 intercept_message[256]; > + __u8 vtl_ret_actions[256]; > } __packed; > > struct hv_enlightened_vmcs { > -- > 2.34.1
On Fri, Nov 04, 2022 at 12:46:57PM +0530, Anirudh Rayabharam wrote: > On Thu, Nov 03, 2022 at 09:56:54PM -0700, Saurabh Sengar wrote: > > The struct hv_vp_assist_page has 24 bytes which is defined as u64[3], > > expand that to expose vtl_entry_reason, vtl_ret_x64rax and vtl_ret_x64rcx > > field. vtl_entry_reason is updated by hypervisor for the entry reason as > > to why the VTL was entered on the virtual processor. > > Guest updates the vtl_ret_* fields to provide the register values to > > restore on VTL return. The specific register values that are restored > > which will be updated on vtl_ret_x64rax and vtl_ret_x64rcx. > > Also added the missing fields for synthetic_time_unhalted_timer_expired, > > virtualization_fault_information and intercept_message. > > > > Signed-off-by: Saurabh Sengar <ssengar@linux.microsoft.com> > > --- > > arch/x86/include/asm/hyperv-tlfs.h | 11 ++++++++++- > > 1 file changed, 10 insertions(+), 1 deletion(-) > > > > diff --git a/arch/x86/include/asm/hyperv-tlfs.h b/arch/x86/include/asm/hyperv-tlfs.h > > index f769b9db4630..b3d0f42853d2 100644 > > --- a/arch/x86/include/asm/hyperv-tlfs.h > > +++ b/arch/x86/include/asm/hyperv-tlfs.h > > @@ -377,11 +377,20 @@ struct hv_nested_enlightenments_control { > > struct hv_vp_assist_page { > > __u32 apic_assist; > > __u32 reserved1; > > - __u64 vtl_control[3]; > > + __u8 vtl_entry_reason; > > This is defined as an enum in the TLFS [1]. We should do the same. > And since the TLFS defines it as an enum it is a 32 bit value and > not a u8. I think we can do that. Let me check this and update on v2. > > > + __u8 vtl_reserved[7]; > > + __u64 vtl_ret_x64rax; > > + __u64 vtl_ret_x64rcx; > > The TLFS groups the above VTL related fields into a struct > HV_VP_VTL_CONTROL. Any reason to not do the same? No particular reason, but this change is simple and sufficient. We can expand in future as the need arises. > > [1] https://learn.microsoft.com/en-us/virtualization/hyper-v-on-windows/tlfs/datatypes/hv_vp_vtl_control > > Thanks, > Anirudh. > > > struct hv_nested_enlightenments_control nested_control; > > __u8 enlighten_vmentry; > > __u8 reserved2[7]; > > __u64 current_nested_vmcs; > > + __u8 synthetic_time_unhalted_timer_expired; > > + __u8 reserved3[7]; > > + __u8 virtualization_fault_information[40]; > > + __u8 reserved4[8]; > > + __u8 intercept_message[256]; > > + __u8 vtl_ret_actions[256]; > > } __packed; > > > > struct hv_enlightened_vmcs { > > -- > > 2.34.1
From: Anirudh Rayabharam <anrayabh@linux.microsoft.com> Sent: Friday, November 4, 2022 12:17 AM > > On Thu, Nov 03, 2022 at 09:56:54PM -0700, Saurabh Sengar wrote: > > The struct hv_vp_assist_page has 24 bytes which is defined as u64[3], > > expand that to expose vtl_entry_reason, vtl_ret_x64rax and vtl_ret_x64rcx > > field. vtl_entry_reason is updated by hypervisor for the entry reason as > > to why the VTL was entered on the virtual processor. > > Guest updates the vtl_ret_* fields to provide the register values to > > restore on VTL return. The specific register values that are restored > > which will be updated on vtl_ret_x64rax and vtl_ret_x64rcx. > > Also added the missing fields for synthetic_time_unhalted_timer_expired, > > virtualization_fault_information and intercept_message. > > > > Signed-off-by: Saurabh Sengar <ssengar@linux.microsoft.com> > > --- > > arch/x86/include/asm/hyperv-tlfs.h | 11 ++++++++++- > > 1 file changed, 10 insertions(+), 1 deletion(-) > > > > diff --git a/arch/x86/include/asm/hyperv-tlfs.h b/arch/x86/include/asm/hyperv- > tlfs.h > > index f769b9db4630..b3d0f42853d2 100644 > > --- a/arch/x86/include/asm/hyperv-tlfs.h > > +++ b/arch/x86/include/asm/hyperv-tlfs.h > > @@ -377,11 +377,20 @@ struct hv_nested_enlightenments_control { > > struct hv_vp_assist_page { > > __u32 apic_assist; > > __u32 reserved1; > > - __u64 vtl_control[3]; > > + __u8 vtl_entry_reason; > > This is defined as an enum in the TLFS [1]. We should do the same. > And since the TLFS defines it as an enum it is a 32 bit value and > not a u8. In the *tlfs.h files we have avoided defining fields with type "enum" because of the potential for variability in number of bytes it occupies. The TLFS documentation assumes an enum is 4 bytes, so in these structure definitions we use a __u32 type to be explicit about the size. We do have enum types defined in the *tlfs.h files, but these are just lists of related constant values, and that's OK. Michael > > > + __u8 vtl_reserved[7]; > > + __u64 vtl_ret_x64rax; > > + __u64 vtl_ret_x64rcx; > > The TLFS groups the above VTL related fields into a struct > HV_VP_VTL_CONTROL. Any reason to not do the same? > > [1] https://learn.microsoft.com/en-us/virtualization/hyper-v-on-windows/tlfs/datatypes/hv_vp_vtl_control > > Thanks, > Anirudh. > > > struct hv_nested_enlightenments_control nested_control; > > __u8 enlighten_vmentry; > > __u8 reserved2[7]; > > __u64 current_nested_vmcs; > > + __u8 synthetic_time_unhalted_timer_expired; > > + __u8 reserved3[7]; > > + __u8 virtualization_fault_information[40]; > > + __u8 reserved4[8]; > > + __u8 intercept_message[256]; > > + __u8 vtl_ret_actions[256]; > > } __packed; > > > > struct hv_enlightened_vmcs { > > -- > > 2.34.1
diff --git a/arch/x86/include/asm/hyperv-tlfs.h b/arch/x86/include/asm/hyperv-tlfs.h index f769b9db4630..b3d0f42853d2 100644 --- a/arch/x86/include/asm/hyperv-tlfs.h +++ b/arch/x86/include/asm/hyperv-tlfs.h @@ -377,11 +377,20 @@ struct hv_nested_enlightenments_control { struct hv_vp_assist_page { __u32 apic_assist; __u32 reserved1; - __u64 vtl_control[3]; + __u8 vtl_entry_reason; + __u8 vtl_reserved[7]; + __u64 vtl_ret_x64rax; + __u64 vtl_ret_x64rcx; struct hv_nested_enlightenments_control nested_control; __u8 enlighten_vmentry; __u8 reserved2[7]; __u64 current_nested_vmcs; + __u8 synthetic_time_unhalted_timer_expired; + __u8 reserved3[7]; + __u8 virtualization_fault_information[40]; + __u8 reserved4[8]; + __u8 intercept_message[256]; + __u8 vtl_ret_actions[256]; } __packed; struct hv_enlightened_vmcs {