From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-14.8 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, NICE_REPLY_A,SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1,USER_IN_DEF_DKIM_WL autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 4B5CFC433B4 for ; Fri, 16 Apr 2021 17:07:11 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 2B1AD610CB for ; Fri, 16 Apr 2021 17:07:11 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S235659AbhDPRHb (ORCPT ); Fri, 16 Apr 2021 13:07:31 -0400 Received: from linux.microsoft.com ([13.77.154.182]:53654 "EHLO linux.microsoft.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S235535AbhDPRHa (ORCPT ); Fri, 16 Apr 2021 13:07:30 -0400 Received: from [192.168.86.23] (c-73-38-52-84.hsd1.vt.comcast.net [73.38.52.84]) by linux.microsoft.com (Postfix) with ESMTPSA id 56DC020B8001; Fri, 16 Apr 2021 10:07:03 -0700 (PDT) DKIM-Filter: OpenDKIM Filter v2.11.0 linux.microsoft.com 56DC020B8001 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.microsoft.com; s=default; t=1618592825; bh=aQ2nMf6p7JAo/eTml5qCXpa9nirMhLaQNfU2xL/fxvM=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=erY+xcbw6X7T0sZPUTOa8e/DXH71J0xDzcbrUOQAz8CGwmHO3FcN5I0beC4rWIAph P/5C9I2Nr1IYiYJetLO10aTjRKsArqPfJJo3POQIidJcjTT6NTXGHg4PKdlXrOp6k8 ZENzTJfu/JenJhLf6I1kLeDGpRpVnK9gVO5vTCz8= Subject: Re: [PATCH v2 4/7] KVM: SVM: hyper-v: Nested enlightenments in VMCB To: Vitaly Kuznetsov , Lan Tianyu , Michael Kelley , Paolo Bonzini , Sean Christopherson , Wanpeng Li , Jim Mattson , Joerg Roedel , Wei Liu , Stephen Hemminger , Haiyang Zhang Cc: "H. Peter Anvin" , Thomas Gleixner , Ingo Molnar , Borislav Petkov , "K. Y. Srinivasan" , x86@kernel.org, kvm@vger.kernel.org, linux-kernel@vger.kernel.org, linux-hyperv@vger.kernel.org, viremana@linux.microsoft.com References: <87v98m7gi4.fsf@vitty.brq.redhat.com> From: Vineeth Pillai Message-ID: <4aaab6f9-7785-5c0a-4f9d-f972ec21888b@linux.microsoft.com> Date: Fri, 16 Apr 2021 13:07:00 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.9.1 MIME-Version: 1.0 In-Reply-To: <87v98m7gi4.fsf@vitty.brq.redhat.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Precedence: bulk List-ID: X-Mailing-List: linux-hyperv@vger.kernel.org On 4/16/2021 4:58 AM, Vitaly Kuznetsov wrote: > >> + >> +#if IS_ENABLED(CONFIG_HYPERV) >> +struct __packed hv_enlightenments { >> + struct __packed hv_enlightenments_control { >> + u32 nested_flush_hypercall:1; >> + u32 msr_bitmap:1; >> + u32 enlightened_npt_tlb: 1; >> + u32 reserved:29; >> + } hv_enlightenments_control; >> + u32 hv_vp_id; >> + u64 hv_vm_id; >> + u64 partition_assist_page; >> + u64 reserved; >> +}; > Enlightened VMCS seems to have the same part: > > struct { > u32 nested_flush_hypercall:1; > u32 msr_bitmap:1; > u32 reserved:30; > } __packed hv_enlightenments_control; > u32 hv_vp_id; > u64 hv_vm_id; > u64 partition_assist_page; > > Would it maybe make sense to unify these two (in case they are the same > thing in Hyper-V, of course)? They are very similar but,  the individual bits are a bit different. SVM struct has an additional bit 'enlightened_npt_tlb'. There might be future changes as well if new enlightenments are designed for performance optimization. So I feel, we can have it as separate structs. >> >> +#define VMCB_ALL_CLEAN_MASK ( \ >> + (1U << VMCB_INTERCEPTS) | (1U << VMCB_PERM_MAP) | \ >> + (1U << VMCB_ASID) | (1U << VMCB_INTR) | \ >> + (1U << VMCB_NPT) | (1U << VMCB_CR) | (1U << VMCB_DR) | \ >> + (1U << VMCB_DT) | (1U << VMCB_SEG) | (1U << VMCB_CR2) | \ >> + (1U << VMCB_LBR) | (1U << VMCB_AVIC) \ >> + ) > What if we preserve VMCB_DIRTY_MAX and drop this newly introduced > VMCB_ALL_CLEAN_MASK (which basically lists all the members of the enum > above)? '1 << VMCB_DIRTY_MAX' can still work. (If the 'VMCB_DIRTY_MAX' > name becomes misleading we can e.g. rename it to VMCB_NATIVE_DIRTY_MAX > or something but I'm not sure it's worth it) I thought of keeping this code because, if we have non-contiguous bits in future, we would need this kinda logic anyways. But I get your point. Will revert this. > >> +#if IS_ENABLED(CONFIG_HYPERV) >> +#define VMCB_HYPERV_CLEAN_MASK (1U << VMCB_HV_NESTED_ENLIGHTENMENTS) >> +#endif > VMCB_HYPERV_CLEAN_MASK is a single bit, why do we need it at all > (BIT(VMCB_HV_NESTED_ENLIGHTENMENTS) is not super long) Agreed. Will change it in next revision. Thanks, Vineeth