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 53A67C7EE24 for ; Tue, 6 Jun 2023 16:55:00 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S238334AbjFFQyq (ORCPT ); Tue, 6 Jun 2023 12:54:46 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:45288 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S238168AbjFFQya (ORCPT ); Tue, 6 Jun 2023 12:54:30 -0400 Received: from mail-yw1-x1149.google.com (mail-yw1-x1149.google.com [IPv6:2607:f8b0:4864:20::1149]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 42E6010EB for ; Tue, 6 Jun 2023 09:54:29 -0700 (PDT) Received: by mail-yw1-x1149.google.com with SMTP id 00721157ae682-565d6824f2dso93877207b3.0 for ; Tue, 06 Jun 2023 09:54:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20221208; t=1686070468; x=1688662468; h=cc:to:from:subject:message-id:references:mime-version:in-reply-to :date:from:to:cc:subject:date:message-id:reply-to; bh=vWfghhT+K/VvYdIHsaVVRXfigb3NJPqkB0cgBd8gNOA=; b=iEDqIHuxrXw0gIUvL9P7CFRGySn8VWahksHLrzLIsF04F3kpysyg/ZXXPgX1/Oq0Cg uNZwWVM0lmG1i9F7IvLGtcvDZxah8CCzeFmyYd8JeZI2cirpwt8HxgWG6YNxcZ/oyeHa Shr68eC/Tvns2OgiaZBrBLT4BmA8I7jF4xpC5y8+kZuzzOkVQcp5L55EaqRj+XlgqlfZ Gv17+BTmWt1BakRBdxSu5TYg8+VYNMtb+aPTYbMhfPJ/FZ2xN1jI3sKNVB31LT/1zIzf AT1jmu9pwQeIqWTDkhnxgRX4LBjvB9V3rKWEN9NGRmT9IyKYu0qddHc/5qvolsBdo1QK u8Ow== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1686070468; x=1688662468; h=cc:to:from:subject:message-id:references:mime-version:in-reply-to :date:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=vWfghhT+K/VvYdIHsaVVRXfigb3NJPqkB0cgBd8gNOA=; b=Bm+ziV8ubC3yr11e41z1grvG0BETsllcZxOrAv1kBdjTIDD+EY1rHTWlw5APjD2lbV M5bp2G7sICmPASfLunJ7Sv02TF79fMsDuVq9oz4G2dKsuC/ASrZr80WQE6VVfq/JFopw zvdjN0xWW/jBNvAQOZPu4xyTrzpWCwGFK+C7M7Zk9GN2Y8sTeMACayEdHXUO04/yxsKL Pcth+PkojIcYqt6O+c0Q/1KhluTAlovTzgvkDlg0DZHLZLDl4GcPQ8hjFFdDHJNM1jnF jS6/byqbN7Xfh72WoLQYCPpVwDN8wqpiuhdsFGguOp82ZiwGCpn1Oa+eb67X4p1SpSEf nQiw== X-Gm-Message-State: AC+VfDwuOr2omDxhiTz0GgrM9wWFjE1rP4INGCzLe14jQruZQSfJ7xHR 3wKofGwjVa3AnuC8hqO9UOtScxIxEls= X-Google-Smtp-Source: ACHHUZ735NOAxJ3G3HjCYdRPxFLDWLMm4QKxC+twRQjzhCgzbcYWiG6wj9pxN63ErpW9hCrFilnr+ZskZ6M= X-Received: from zagreus.c.googlers.com ([fda3:e722:ac3:cc00:7f:e700:c0a8:5c37]) (user=seanjc job=sendgmr) by 2002:a81:d208:0:b0:564:c5fd:6d98 with SMTP id x8-20020a81d208000000b00564c5fd6d98mr1286497ywi.10.1686070468519; Tue, 06 Jun 2023 09:54:28 -0700 (PDT) Date: Tue, 6 Jun 2023 09:54:26 -0700 In-Reply-To: Mime-Version: 1.0 References: <20230506030435.80262-1-chao.gao@intel.com> Message-ID: Subject: Re: [PATCH] KVM: x86: Track supported ARCH_CAPABILITIES in kvm_caps From: Sean Christopherson To: Chao Gao Cc: Xiaoyao Li , kvm@vger.kernel.org, Paolo Bonzini , Thomas Gleixner , Ingo Molnar , Borislav Petkov , Dave Hansen , x86@kernel.org, "H. Peter Anvin" , linux-kernel@vger.kernel.org, Jim Mattson Content-Type: text/plain; charset="us-ascii" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, May 29, 2023, Chao Gao wrote: > On Thu, May 18, 2023 at 10:33:15AM -0700, Sean Christopherson wrote: > >FWIW, this trainwreck is another reason why I'm not going to look at the proposed > >"Intel IA32_SPEC_CTRL Virtualization" crud until external forces dictate that I > >do so. I have zero confidence that a paravirt interface defined by hardware > >vendors to fiddle with mitigations will be sane, flexible, and extensible. > > Hi Sean, > > Just to confirm we are on the same page: > > "Intel IA32_SPEC_CTRL Virtualization" series consists of 3 parts: > > 1. Expose BHI_CTRL, RRSBA_CTRL to guests. They are hardware mitigations to > disable BHI and RRSBA behaviors and can be used by both guest/host. > > 2. Enable IA32_SPEC_CTRL Virtualization which is a VMX feature. This is for KVM > to effectively lock some bits of IA32_SPEC_CTRL MSR when guests are running. > > 3. Implement the paravirt interface (the virtual MSRs) for guests to report > software mitigations in-use. KVM can utilize such information to enable > hardware mitigations for guests transparently to address software mitigation > effectiveness issues caused by CPU microarchitecture changes (RRSBA behavior, > size of branch history table). > > As per my understanding, your concerns are primarily focused on #3, the > paravirt interface, rather than the entire series. Am I correct in assuming that > you do not oppose #1 and #2? Yes, correct. I definitely recommend posting #1 and #2 separately from the paravirt interface, I ignored the entire series without realizing there is real hardware support in there. > You previously mentioned that the paravirt interface was not common [1], and > this time, you expressed an expectation for the interface to be "sane, flexible, > and extensible." To ensure clarity, I want to confirm my interpretation of > your expectations: > > 1. The interface should not be tied to a specific CPU vendor but instead be > beneficial for Intel and AMD (and even ARM, and potentially others). > > 2. The interface should have the capability to solve other issues (e.g, > coordinate mitigations in guest/host to address other perf/function issues), > not limited to software mitigation effectiveness on Intel CPUs. > 3. The interface should be extendable by VMMs rather than relying on hardware > vendors rolling out new spec. This enables VMM developers to propose new > ideas to coordinate mitigations in guest/host. Ya, that's more or less my opinion. Even more than allowing VMM developers to extend/define the interface, I want the definition of the interace to be a community/collaborative effort. LKML has active representatives from all of the major (known) hypervisors, so it shouldn't be *that* hard to figure out a way to make the interface community driven. Note that it doesn't necessarily have to be VMM developers, e.g. many of the people that are intimately familiar with the mitigations aren't virtualization folks. > Please let me know if I missed any key points or if any of the above statements > do not align with your expectations. > > [1]: https://lore.kernel.org/all/Y6Sin1bmLN10yvMw@google.com/