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 Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 50A25C28D13 for ; Mon, 22 Aug 2022 17:01:57 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S234589AbiHVRB4 (ORCPT ); Mon, 22 Aug 2022 13:01:56 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:48942 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S234921AbiHVRBz (ORCPT ); Mon, 22 Aug 2022 13:01:55 -0400 Received: from mail-pl1-x636.google.com (mail-pl1-x636.google.com [IPv6:2607:f8b0:4864:20::636]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id ED6DC1582D for ; Mon, 22 Aug 2022 10:01:53 -0700 (PDT) Received: by mail-pl1-x636.google.com with SMTP id 2so10510459pll.0 for ; Mon, 22 Aug 2022 10:01:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc; bh=hISs2+Lj2zz9ocjh89OwJmc05bBvn26H1BdqKuz/c9o=; b=NOz0ftgWBUONI4K6xRlOuRT36flqRPmzJBevhTDG7H5UWwyKFRMINFxIpdmfd4u4QI CaJiP6wqGLU2LDVGRVz1EwRbz+Ba9rpv5JXI5fZr7VxxA2CBqyD3scB9K9jOID9Ph3Rx 0dV6+sZUwQjuybtiPFUZh66o+aKLGY9PHr0Ya/h/TmboC0deyk2mkIs1yLguUKQEOka3 tKvfKKO2cQJT/3OfS9J5fMXMPj8ECZ7c/kr7ZX1ETDKk15j//qPrPcpp2bnY+mEpeSL4 gjiNC6awGs/OnLdVUJ9f7qkRCUxqCvP8e5uKPOiM4Mz3EEeqKlzHQf8A8eNvGatJHh74 1G7A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc; bh=hISs2+Lj2zz9ocjh89OwJmc05bBvn26H1BdqKuz/c9o=; b=sDh9LqdRb3eOkUC3f5M6kaLVkQXaYJwmUWmKPogWM0CW/WVL86xMpVPQibjRLQa8Qq /J/Kcs+0ZWeRW5wlSPhIHkGYw82/Fxy+MBBjF8CKOBrPJw0QdUbJm6+cIOza7KO+uLqV ZnFm9exmypvc2oJfmFVT0wrQj27XnTkHp9HZ22EY0+c8WBXMchGqqql7u2ynHba55vM0 T3sZGx0mFiQ78yo0lEz0J9AyRlvQ/hc0L9B2Q0y8p1sFj3FwKYpBatnYvisxbkmN9LJt jAjljse5hjsA7HfEx5RFTgS6PAd1mNeu9UKOimSMLeK2QGVTJM/rMRImZH0W2VS+HWqu 46gA== X-Gm-Message-State: ACgBeo1EXethiP9t8tWn8kTopVXSoTlTWIJ/M0Dge6zTzH5BNzLHNZNA Fa0woSFHInUjPbdcnsUqpS6xxQ== X-Google-Smtp-Source: AA6agR6y6MvImrDfOKpRHaP76KrDOZE2lPG3W4xYzVQy6r86lB96UyXhh1HAfgfxABjIE9OT1hMoCg== X-Received: by 2002:a17:90b:1c82:b0:1ee:eb41:b141 with SMTP id oo2-20020a17090b1c8200b001eeeb41b141mr24430852pjb.143.1661187713337; Mon, 22 Aug 2022 10:01:53 -0700 (PDT) Received: from google.com (7.104.168.34.bc.googleusercontent.com. [34.168.104.7]) by smtp.gmail.com with ESMTPSA id u64-20020a627943000000b0052c7ff2ac74sm9191026pfc.17.2022.08.22.10.01.52 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 22 Aug 2022 10:01:52 -0700 (PDT) Date: Mon, 22 Aug 2022 17:01:49 +0000 From: Sean Christopherson To: Vitaly Kuznetsov Cc: kvm@vger.kernel.org, Paolo Bonzini , Anirudh Rayabharam , Wanpeng Li , Jim Mattson , Maxim Levitsky , Nathan Chancellor , Michael Kelley , linux-hyperv@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH v5 03/26] x86/hyperv: Update 'struct hv_enlightened_vmcs' definition Message-ID: References: <20220802160756.339464-1-vkuznets@redhat.com> <20220802160756.339464-4-vkuznets@redhat.com> <875yiptvsc.fsf@redhat.com> <87czcsskkj.fsf@redhat.com> <87edx8xn8h.fsf@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87edx8xn8h.fsf@redhat.com> Precedence: bulk List-ID: X-Mailing-List: linux-hyperv@vger.kernel.org On Mon, Aug 22, 2022, Vitaly Kuznetsov wrote: > Sean Christopherson writes: > > > On Mon, Aug 22, 2022, Vitaly Kuznetsov wrote: > >> So I reached out to Microsoft and their answer was that for all these new > >> eVMCS fields (including *PerfGlobalCtrl) observing architectural VMX > >> MSRs should be enough. *PerfGlobalCtrl case is special because of Win11 > >> bug (if we expose the feature in VMX feature MSRs but don't set > >> CPUID.0x4000000A.EBX BIT(0) it just doesn't boot). > > > > I.e. TSC_SCALING shouldn't be gated on the flag? If so, then the 2-D array approach > > is overkill since (a) the CPUID flag only controls PERF_GLOBAL_CTRL and (b) we aren't > > expecting any more flags in the future. > > > > Unfortunately, we have to gate the presence of these new features on > something, otherwise VMM has no way to specify which particular eVMCS > "revision" it wants (TL;DR: we will break migration). > > My initial implementation was inventing 'eVMCS revision' concept: > https://lore.kernel.org/kvm/20220629150625.238286-7-vkuznets@redhat.com/ > > which is needed if we don't gate all these new fields on CPUID.0x4000000A.EBX BIT(0). > > Going forward, we will still (likely) need something when new fields show up. My comments from that thread still apply. Adding "revisions" or feature flags isn't maintanable, e.g. at best KVM will end up with a ridiculous number of flags. Looking at QEMU, which I strongly suspect is the only VMM that enables KVM_CAP_HYPERV_ENLIGHTENED_VMCS, it does the sane thing of enabling the capability before grabbing the VMX MSRs. So, why not simply apply filtering for host accesses as well? E.g. /* * New Enlightened VMCS fields always lag behind their hardware * counterparts, filter out fields that are not yet defined. */ if (vmx->nested.enlightened_vmcs_enabled) nested_evmcs_filter_control_msr(vcpu, msr_info); and then the eVMCS can end up being: static bool evmcs_has_perf_global_ctrl(struct kvm_vcpu *vcpu) { struct kvm_vcpu_hv *hv_vcpu = to_hv_vcpu(vcpu); /* * PERF_GLOBAL_CTRL is filtered only for guest accesses, and all guest * accesses should be gated on Hyper-V being enabled and initialized. */ if (WARN_ON_ONCE(!hv_vcpu)) return false; return hv_vcpu->cpuid_cache.nested_ebx & HV_X64_NESTED_EVMCS1_PERF_GLOBAL_CTRL; } static u32 evmcs_get_unsupported_ctls(struct kvm_vcpu *vcpu, u32 msr_index, bool host_initiated) { u32 unsupported_ctrls; switch (msr_index) { case MSR_IA32_VMX_EXIT_CTLS: case MSR_IA32_VMX_TRUE_EXIT_CTLS: unsupported_ctrls = EVMCS1_UNSUPPORTED_VMEXIT_CTRL; if (!host_initiated && !evmcs_has_perf_global_ctrl(vcpu)) unsupported_ctrls |= VM_EXIT_LOAD_IA32_PERF_GLOBAL_CTRL; return unsupported_ctrls; case MSR_IA32_VMX_ENTRY_CTLS: case MSR_IA32_VMX_TRUE_ENTRY_CTLS: unsupported_ctrls = EVMCS1_UNSUPPORTED_VMENTRY_CTRL; if (!host_initiated && !evmcs_has_perf_global_ctrl(vcpu)) unsupported_ctrls |= VM_ENTRY_LOAD_IA32_PERF_GLOBAL_CTRL; return unsupported_ctrls; case MSR_IA32_VMX_PROCBASED_CTLS2: return EVMCS1_UNSUPPORTED_2NDEXEC; case MSR_IA32_VMX_TRUE_PINBASED_CTLS: case MSR_IA32_VMX_PINBASED_CTLS: return EVMCS1_UNSUPPORTED_PINCTRL; case MSR_IA32_VMX_VMFUNC: return EVMCS1_UNSUPPORTED_VMFUNC; default: KVM_BUG_ON(1, vcpu->kvm); return 0; } } void nested_evmcs_filter_control_msr(struct kvm_vcpu *vcpu, struct msr_data *msr_info) { u64 unsupported_ctrls; if (!msr_info->host_initiated && !vcpu->arch.hyperv_enabled) return; unsupported_ctrls = evmcs_get_unsupported_ctls(vcpu, msr_info->index, msr_info->host_initiated); if (msr_info->index == MSR_IA32_VMX_VMFUNC) msr_info->data &= ~unsupported_ctrls; else msr_info->data &= ~(unsupported_ctrls << 32); } static bool nested_evmcs_is_valid_controls(struct kvm_vcpu *vcpu, u32 msr_index, u32 val) { return val & evmcs_get_unsupported_ctls(vcpu, msr_index, false); }