Received: by 2002:a6b:500f:0:0:0:0:0 with SMTP id e15csp242837iob; Mon, 2 May 2022 18:17:14 -0700 (PDT) X-Google-Smtp-Source: ABdhPJya5kd4pAx6dmXcqV5+y/UlV3KtSavHPCvP1OtAYmkNSkpWjaz7G/XcDPohnJoBcMCyufQ2 X-Received: by 2002:a63:84c6:0:b0:3ab:23f6:db27 with SMTP id k189-20020a6384c6000000b003ab23f6db27mr12127182pgd.275.1651540634290; Mon, 02 May 2022 18:17:14 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1651540634; cv=none; d=google.com; s=arc-20160816; b=IKI9YSS62bW4/vN1PnFTU90joAjvqRVslc1/CRbQ4hx/6AmYEi0NwSKxLXXXRJyh8U wUMI9ysihLx2VpEHfP3go9LfLHzDz5yox7zXEgd1EPS2punx14x9R7O7ZoZnhR3JUqPc 5fofPcqZCSWosHmltyQNJT0S4zE3zVGouGKvHVAlFyaBaNf/i6h3nW8e4DrURcUu0cFH gWtzK29S1jiyc1Nln+Mpg9VoTwQ2R2O6Y3an/3ALvRfdqsukqcU+XxNPaUR3H/kDtwVY genABOhy2cTHX3XttzYPW9UnX/H+nyfAWk+/+nMk4vJUoZ97MubyTwi3C74fzZnp4L3p ctcw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-transfer-encoding :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:dkim-signature; bh=3O6m7gsP+Q15sV5A9sj6v9CSQ9u8JCS/o5mGbHIZ3EY=; b=vf8xBt4NVz9DCLkx0BJbhxINwywi2alL8+jo3qAr9cC1FOpiHfIEzByw4HBnBcj91T xxXNnNoQwNYOEJldHt187zOKRUW7hwoK3tJz0cZmCikXT8107z9pL+fxKZV94oDh5U+G YGLZku4dYDSNRnAeNOlVdBeyo68177IIdfA0IPjnG6T+SnMnakLMcfKqmOpFHE0xhaKj pElYW3w6B/1u+20XTz8o+f6q8vk2Y0T7+ytPwqM94yvxjhtHHstVBsc/CSoC5IJVfLH0 67QNufc1Oin5JwdQNvStDyT/vMIuP+bHf9AUBL6Of8G51JRJHsKu6HIKgwhU6WeDZuHd qarg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@alien8.de header.s=dkim header.b="C+/uh9ci"; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=alien8.de Return-Path: Received: from lindbergh.monkeyblade.net (lindbergh.monkeyblade.net. [2620:137:e000::1:18]) by mx.google.com with ESMTPS id m5-20020a170902f64500b00153b2d16543si15375436plg.331.2022.05.02.18.17.13 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 02 May 2022 18:17:14 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:18 as permitted sender) client-ip=2620:137:e000::1:18; Authentication-Results: mx.google.com; dkim=pass header.i=@alien8.de header.s=dkim header.b="C+/uh9ci"; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=alien8.de Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id 1890260D96; Mon, 2 May 2022 17:56:52 -0700 (PDT) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S237662AbiD3QMa (ORCPT + 99 others); Sat, 30 Apr 2022 12:12:30 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:55974 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231685AbiD3QM3 (ORCPT ); Sat, 30 Apr 2022 12:12:29 -0400 Received: from mail.skyhub.de (mail.skyhub.de [5.9.137.197]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 5FDD85E140; Sat, 30 Apr 2022 09:09:06 -0700 (PDT) Received: from zn.tnic (p5de8eeb4.dip0.t-ipconnect.de [93.232.238.180]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.skyhub.de (SuperMail on ZX Spectrum 128k) with ESMTPSA id DE3691EC0445; Sat, 30 Apr 2022 18:09:00 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alien8.de; s=dkim; t=1651334941; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=3O6m7gsP+Q15sV5A9sj6v9CSQ9u8JCS/o5mGbHIZ3EY=; b=C+/uh9ciNP7u3UTNMwVgALCRLpJA6vbWXsvn825GyZFBliE78epk76kGCChw3PpvEqGUvA W33lTP/7kOzELZSt2zaubZpzu/l7bnOSxk44QUPozTTPcdnqw5vkd845EnXhwQCUBixVb4 KdGCNttpqX7qbiIuGdL16AVnCMpfue4= Date: Sat, 30 Apr 2022 18:08:57 +0200 From: Borislav Petkov To: Jon Kohler Cc: Sean Christopherson , Thomas Gleixner , Ingo Molnar , Dave Hansen , "x86@kernel.org" , "H. Peter Anvin" , Paolo Bonzini , Vitaly Kuznetsov , Wanpeng Li , Jim Mattson , Joerg Roedel , Josh Poimboeuf , Peter Zijlstra , Balbir Singh , Kim Phillips , "linux-kernel@vger.kernel.org" , "kvm@vger.kernel.org" , Andrea Arcangeli , Kees Cook , Waiman Long Subject: Re: [PATCH v3] x86/speculation, KVM: only IBPB for switch_mm_always_ibpb on vCPU load Message-ID: References: <645E4ED5-F6EE-4F8F-A990-81F19ED82BFA@nutanix.com> <4E46337F-79CB-4ADA-B8C0-009E7500EDF8@nutanix.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <4E46337F-79CB-4ADA-B8C0-009E7500EDF8@nutanix.com> X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,RDNS_NONE,SPF_HELO_NONE,T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sat, Apr 30, 2022 at 02:50:35PM +0000, Jon Kohler wrote: > This is 100% a fair ask, I appreciate the diligence, as we’ve all been there > on the ‘other side’ of changes to complex areas and spend hours digging on > git history, LKML threads, SDM/APM, and other sources trying to derive > why the heck something is the way it is. Yap, that's basically proving my point and why I want stuff to be properly documented so that the question "why was it done this way" can always be answered satisfactorily. > AFAIK, the KVM IBPB is avoided when switching in between vCPUs > belonging to the same vmcs/vmcb (i.e. the same guest), e.g. you could > have one VM highly oversubscribed to the host and you wouldn’t see > either the KVM IBPB or the switch_mm IBPB. All good. > > Reference vmx_vcpu_load_vmcs() and svm_vcpu_load() and the > conditionals prior to the barrier. So this is where something's still missing. > However, the pain ramps up when you have a bunch of separate guests, > especially with a small amount of vCPUs per guest, so the switching is more > likely to be in between completely separate guests. If the guests are completely separate, then it should fall into the switch_mm() case. Unless it has something to do with, as I looked at the SVM side of things, the VMCBs: if (sd->current_vmcb != svm->vmcb) { So it is not only different guests but also within the same guest and when the VMCB of the vCPU is not the current one. But then if VMCB of the vCPU is not the current, per-CPU VMCB, then that CPU ran another guest so in order for that other guest to attack the current guest, then its branch pred should be flushed. But I'm likely missing a virt aspect here so I'd let Sean explain what the rules are... Thx. -- Regards/Gruss, Boris. https://people.kernel.org/tglx/notes-about-netiquette