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=-0.6 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS 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 2EDF4C432C0 for ; Wed, 20 Nov 2019 10:13:51 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 0563422440 for ; Wed, 20 Nov 2019 10:13:51 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="tum3HFhY" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728515AbfKTKNu (ORCPT ); Wed, 20 Nov 2019 05:13:50 -0500 Received: from mail-oi1-f195.google.com ([209.85.167.195]:38746 "EHLO mail-oi1-f195.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728406AbfKTKNt (ORCPT ); Wed, 20 Nov 2019 05:13:49 -0500 Received: by mail-oi1-f195.google.com with SMTP id a14so21993015oid.5; Wed, 20 Nov 2019 02:13:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=lde2KhjY7wfAoIiWkWWnbWFwuvtD6AW2ng2O9SrZAQI=; b=tum3HFhYbfwE2ky4iNe0IhOcN4+nZNb/DMn8iw2S81C99M+x5e2EpQ8Kac8CGk22dR SgZdMXeUc7J3ZIhOyA5CkcJtybYPj7wt4WMrvym3C5fkFUU6DtSkbg9gpizwYk7xNNTm pyFyJsPwCpU+rSp2zDiF49sl68Fl0syhG0ar6BTMKk+n0C7Xdp/Ba6qJ62Ldu+e/Vq4S IUWuV5f55JU4oe0yXJObBkBRBhvEHzpfhvr3gOvVP6Ji4F48VB90D0ljh8mW/5BGPYvD j9J76EzK4ABxmgE7DW3/pCIxDs0qJX/Wa9k+JCjFJOQd7Qsyy8xlwKh7Paz66kocFjg9 seRw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=lde2KhjY7wfAoIiWkWWnbWFwuvtD6AW2ng2O9SrZAQI=; b=dp2Asg+LT2tjCaHgCNShZ0aqsQkE+kxWcfc+Hw30zjZc8E18O5c9Ja7XSv2qgXKLUl WGfjhHJg0R5bU/y4zMJcTFZyE1nZu39ea6meH1nKHkp6FLSJdBrW57mq8adK0nPQlNGn 4wM+LqA1Mvw2Z1p6YIMrtDbmueuSDOuD/0LzlHRjRVQZBjyLUgcfO8Ix5Jha9+tPg4F5 uNpwEcemHjbtTCV6iTHih3ZMZace2SV0aqHp/u7W0ELpz3RCAikZmCFxv3Uj7ZkZi0px +yQXLlYpFUzJDEFX97jNgj2PXQqZhpJZZ0TnJC1BN6wePCrlSTLBw1aZ2Dlaz80PfF1U eUWg== X-Gm-Message-State: APjAAAUEFKoluQjdy5gPM2cQyofsUydNXEzRuTMO2jLrjSBAr7T2oPII LsP8SA2AOYg9ogIZsMw4HRjte/xtN11J4SNaMCU= X-Google-Smtp-Source: APXvYqxZSfWMxyflhcnT9tM5lOwDlMuKYqjC59kb27nMC0uIT+CCiDvQijJ51b9M9rmiGv4h+QUrJ21pTECzguY3nOA= X-Received: by 2002:aca:4a84:: with SMTP id x126mr1978871oia.47.1574244828632; Wed, 20 Nov 2019 02:13:48 -0800 (PST) MIME-Version: 1.0 References: <20191105161737.21395-1-vkuznets@redhat.com> <20191105200218.GF3079@worktop.programming.kicks-ass.net> <20191105232528.GF23297@linux.intel.com> <20191106083235.GP4131@hirez.programming.kicks-ass.net> In-Reply-To: <20191106083235.GP4131@hirez.programming.kicks-ass.net> From: Wanpeng Li Date: Wed, 20 Nov 2019 18:13:41 +0800 Message-ID: Subject: Re: [PATCH RFC] KVM: x86: tell guests if the exposed SMT topology is trustworthy To: Peter Zijlstra , Paolo Bonzini Cc: Sean Christopherson , Vitaly Kuznetsov , kvm , "the arch/x86 maintainers" , Thomas Gleixner , Ingo Molnar , Borislav Petkov , Jim Mattson , Liran Alon , LKML , "H. Peter Anvin" Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Paolo, On Wed, 6 Nov 2019 at 16:34, Peter Zijlstra wrote: > > On Tue, Nov 05, 2019 at 03:25:28PM -0800, Sean Christopherson wrote: > > On Tue, Nov 05, 2019 at 09:02:18PM +0100, Peter Zijlstra wrote: > > > On Tue, Nov 05, 2019 at 05:17:37PM +0100, Vitaly Kuznetsov wrote: > > > > Virtualized guests may pick a different strategy to mitigate hardware > > > > vulnerabilities when it comes to hyper-threading: disable SMT completely, > > > > use core scheduling, or, for example, opt in for STIBP. Making the > > > > decision, however, requires an extra bit of information which is currently > > > > missing: does the topology the guest see match hardware or if it is 'fake' > > > > and two vCPUs which look like different cores from guest's perspective can > > > > actually be scheduled on the same physical core. Disabling SMT or doing > > > > core scheduling only makes sense when the topology is trustworthy. > > > > > > > > Add two feature bits to KVM: KVM_FEATURE_TRUSTWORTHY_SMT with the meaning > > > > that KVM_HINTS_TRUSTWORTHY_SMT bit answers the question if the exposed SMT > > > > topology is actually trustworthy. It would, of course, be possible to get > > > > away with a single bit (e.g. 'KVM_FEATURE_FAKE_SMT') and not lose backwards > > > > compatibility but the current approach looks more straightforward. > > > > > > The only way virt topology can make any sense what so ever is if the > > > vcpus are pinned to physical CPUs. > > > > > > And I was under the impression we already had a bit for that (isn't it > > > used to disable paravirt spinlocks and the like?). But I cannot seem to > > > find it in a hurry. > > > > Yep, KVM_HINTS_REALTIME does what you describe. > > *sigh*, that's a pretty shit name for it :/ My original commit name this to KVM_HINTS_DEDICATED, commit a4429e53c (KVM: Introduce paravirtualization hints and KVM_HINTS_DEDICATED), could we revert the KVM_HINTS_REALTIME renaming? A lot of guys confused by this renaming now, Peterz, Marcelo ("The previous definition was much better IMO: HINTS_DEDICATED". https://lkml.org/lkml/2019/8/26/855). Wanpeng