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 53607C61DA4 for ; Fri, 27 Jan 2023 22:15:28 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232755AbjA0WP1 (ORCPT ); Fri, 27 Jan 2023 17:15:27 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:51976 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232714AbjA0WPX (ORCPT ); Fri, 27 Jan 2023 17:15:23 -0500 Received: from mail-pj1-x102b.google.com (mail-pj1-x102b.google.com [IPv6:2607:f8b0:4864:20::102b]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 5669986E8D for ; Fri, 27 Jan 2023 14:15:21 -0800 (PST) Received: by mail-pj1-x102b.google.com with SMTP id b24-20020a17090a551800b0022beefa7a23so9964426pji.5 for ; Fri, 27 Jan 2023 14:15:21 -0800 (PST) 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:subject:date:message-id:reply-to; bh=p1OM1KDXb9Qfz9gyDWmx+cdbCnJyOugwK6Di6FN+pM4=; b=tknPbBbY/BuP9xKGpbiwIDE12BkTb/uGULXxa41kQhP3ug6i4muvEqVRAp+soJ++27 bpa1DX2Zl/s0Oe5ebh99rFixL1SBn0Z6EJJFzgUR5u99qsCW0kZTFGC0kAq5lQk5qQYx /JVe/h9NM6W1IQuM9L5NCkNkKP3sVzVdgXTr5OgZGsM4+4VrGJYymmmY9Tcfk9TDjzac ci3OT1TjgtdAa/bZjYi+YppIbRXdzroqth1BqZatRUJiuDEJD673/QGGy0IUtc/gyM/t 1jTqohB24syztLvDiH93nscjloxyZ68o4S3GbQov9gg/pQzm/H3B052ScnygVxpn5oSm GK8Q== 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:subject:date :message-id:reply-to; bh=p1OM1KDXb9Qfz9gyDWmx+cdbCnJyOugwK6Di6FN+pM4=; b=3cU9OfS48uukQnh2W9O7oPtfiL54M67FW6JYdtOcjACNDYE89G/muJLR0nXOTL/gLN q9wqWq7RkI83BJeq0Ek4DYXRAPYIOlSzRzY6pPHqmhxM4v6nCThKvaX/EZa1kZJFgu2/ ptZj6PBQ4a5H3wttnIe+esAyxBb8cH/LnRUe3LYGrqAsQx2GXVLWi/q5/WppQHaT3TzE 7BNeljZxs8iLnQnau/UFmssPIaslnLshQc4k9Z3/iwseE9ABhBAqIJSwcTwUWMeyIu/l tYmmpG9Q0oiHYvchJgx6i3Yw1z9M/TkIXCd6agxRoOE566D+ah7MN+66jg79PLUJBGkp Ojuw== X-Gm-Message-State: AO0yUKWj9x4S2cmgo37vq1f/yQ60sIebD7D1CTISgx1jaRDlCZ3RwwYY 9eTjEGzX39+xGXdw1aQA+9TdAg== X-Google-Smtp-Source: AK7set/dfl3SMw9T0vaX3jTrYx4cah3xDIfPXHg+NIow16SNVI2DXH1eHSxqEkudoR+OqX6mAaqR8w== X-Received: by 2002:a05:6a20:c18c:b0:b8:e33c:f160 with SMTP id bg12-20020a056a20c18c00b000b8e33cf160mr171347pzb.0.1674857720691; Fri, 27 Jan 2023 14:15:20 -0800 (PST) Received: from google.com (7.104.168.34.bc.googleusercontent.com. [34.168.104.7]) by smtp.gmail.com with ESMTPSA id c64-20020a624e43000000b00586fbbdf6e4sm3126948pfb.34.2023.01.27.14.15.19 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 27 Jan 2023 14:15:19 -0800 (PST) Date: Fri, 27 Jan 2023 22:15:15 +0000 From: Sean Christopherson To: Yang Weijiang Cc: pbonzini@redhat.com, jmattson@google.com, kvm@vger.kernel.org, linux-kernel@vger.kernel.org, like.xu.linux@gmail.com, kan.liang@linux.intel.com, wei.w.wang@intel.com, Like Xu Subject: Re: [PATCH v2 15/15] KVM: x86/cpuid: Advertise Arch LBR feature in CPUID Message-ID: References: <20221125040604.5051-1-weijiang.yang@intel.com> <20221125040604.5051-16-weijiang.yang@intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20221125040604.5051-16-weijiang.yang@intel.com> Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Nov 24, 2022, Yang Weijiang wrote: > Add Arch LBR feature bit in CPU cap-mask to expose the feature. > Only max LBR depth is supported for guest, and it's consistent > with host Arch LBR settings. > > Co-developed-by: Like Xu > Signed-off-by: Like Xu > Signed-off-by: Yang Weijiang > Reviewed-by: Kan Liang > --- > arch/x86/kvm/cpuid.c | 36 +++++++++++++++++++++++++++++++++++- > 1 file changed, 35 insertions(+), 1 deletion(-) > > diff --git a/arch/x86/kvm/cpuid.c b/arch/x86/kvm/cpuid.c > index 85e3df6217af..60b3c591d462 100644 > --- a/arch/x86/kvm/cpuid.c > +++ b/arch/x86/kvm/cpuid.c > @@ -134,6 +134,19 @@ static int kvm_check_cpuid(struct kvm_vcpu *vcpu, > if (vaddr_bits != 48 && vaddr_bits != 57 && vaddr_bits != 0) > return -EINVAL; > } > + if (kvm_cpu_cap_has(X86_FEATURE_ARCH_LBR)) { > + best = cpuid_entry2_find(entries, nent, 0x1c, 0); > + if (best) { > + unsigned int eax, ebx, ecx, edx; > + > + /* Reject user-space CPUID if depth is different from host's.*/ > + cpuid_count(0x1c, 0, &eax, &ebx, &ecx, &edx); > + > + if ((eax & 0xff) && > + (best->eax & 0xff) != BIT(fls(eax & 0xff) - 1)) > + return -EINVAL; > + } > + } Drop this. While I think everyone agrees that KVM's CPUID uAPI sucks, the status quo is to let userspace shoot itself in the foot. I.e. disallow enabling LBRs with a "bad" config, but don't reject the ioctl(). > > /* > * Exposing dynamic xfeatures to the guest requires additional > @@ -652,7 +665,7 @@ void kvm_set_cpu_caps(void) > F(SPEC_CTRL_SSBD) | F(ARCH_CAPABILITIES) | F(INTEL_STIBP) | > F(MD_CLEAR) | F(AVX512_VP2INTERSECT) | F(FSRM) | > F(SERIALIZE) | F(TSXLDTRK) | F(AVX512_FP16) | > - F(AMX_TILE) | F(AMX_INT8) | F(AMX_BF16) > + F(AMX_TILE) | F(AMX_INT8) | F(AMX_BF16) | F(ARCH_LBR) As mentioned earlier, omit this and make it opt-in. > ); > > /* TSC_ADJUST and ARCH_CAPABILITIES are emulated in software. */ > @@ -1074,6 +1087,27 @@ static inline int __do_cpuid_func(struct kvm_cpuid_array *array, u32 function) > goto out; > } > break; > + /* Architectural LBR */ > + case 0x1c: { > + u32 lbr_depth_mask = entry->eax & 0xff; > + > + if (!lbr_depth_mask || > + !kvm_cpu_cap_has(X86_FEATURE_ARCH_LBR)) { > + entry->eax = entry->ebx = entry->ecx = entry->edx = 0; > + break; > + } > + /* > + * KVM only exposes the maximum supported depth, which is the > + * fixed value used on the host side. > + * KVM doesn't allow VMM userspace to adjust LBR depth because > + * guest LBR emulation depends on the configuration of host LBR > + * driver. > + */ > + lbr_depth_mask = BIT((fls(lbr_depth_mask) - 1)); C'mon. More unnecessary dependencies on perf using the max depth. > + entry->eax &= ~0xff; > + entry->eax |= lbr_depth_mask; > + break; > + } > /* Intel AMX TILE */ > case 0x1d: > if (!kvm_cpu_cap_has(X86_FEATURE_AMX_TILE)) { > -- > 2.27.0 >