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=-11.8 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH, MAILING_LIST_MULTI,MENTIONS_GIT_HOSTING,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=ham 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 551CEC56202 for ; Thu, 12 Nov 2020 13:40:14 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 02E4D2224A for ; Thu, 12 Nov 2020 13:40:13 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=joelfernandes.org header.i=@joelfernandes.org header.b="BbzIHIwi" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728601AbgKLNkM (ORCPT ); Thu, 12 Nov 2020 08:40:12 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:51448 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728583AbgKLNkI (ORCPT ); Thu, 12 Nov 2020 08:40:08 -0500 Received: from mail-qt1-x844.google.com (mail-qt1-x844.google.com [IPv6:2607:f8b0:4864:20::844]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id B0B8CC0613D1 for ; Thu, 12 Nov 2020 05:40:07 -0800 (PST) Received: by mail-qt1-x844.google.com with SMTP id n63so3916856qte.4 for ; Thu, 12 Nov 2020 05:40:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelfernandes.org; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=81nAiBsdjpUldAoR9BpToGC3oCIjPVlFYGU9myModZ4=; b=BbzIHIwiCNuJ39Jv6dogY5LVDT633gdffeAHIIGTHescq16SgewDuzhGpwFpJEdAXm 46Ax3+u4PWxcXVnaws5U/dZjcWyUC4pG+zgBth1X/rzkGkUczFAbSvtt1KUQnncUMT+g +pQrwaQEor3vVs9YVl/hHR3eLVKh4w5IADjaI= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=81nAiBsdjpUldAoR9BpToGC3oCIjPVlFYGU9myModZ4=; b=KiZueWRGxMU76e1msRAzJ6IqPX22sIt7WbOi0PX8rlzPH9NyFBa5gbGe0nOgxprxB3 ljH8TTH0ci3TPiMFAfZoQgl4y16hQDRM3IzRD+gypWigVx+SvBiWl+0/P/K9IQFz4nx5 k7I8KK21bjxh90G1Z2gG3kM8N43UU9aRyRnDcsppKcm2lhgzC/x6+0PZM5TE6CdJ5gmy k30CafCCqruEUCfW3gl9cq3SLFhMX0XBWYoZensWG23kYSVmEusBa9c/fR4ITHUnKxN/ Q+TB5u50mkPLlnnG3RVVIiPqWbb9fFWh7dQJmullQcY9R1nmKmh9h8URjQGXACkp4hwq 62mw== X-Gm-Message-State: AOAM530Ln1xDw9Yt0tLLxeNW+mEPOH+bOeSKUt8oyEhTZJIUFNw3gY1n u3vOKjMm56uY5Vk8h32BRqn8Qw== X-Google-Smtp-Source: ABdhPJx02E3TXN6Z7yGOr/E6siNbzwJJe09wHS/Qp8p8JPcamRAjDWYUtYA6mg5oTIE9/fi18AtUlA== X-Received: by 2002:aed:3048:: with SMTP id 66mr29272092qte.374.1605188406848; Thu, 12 Nov 2020 05:40:06 -0800 (PST) Received: from localhost ([2620:15c:6:411:cad3:ffff:feb3:bd59]) by smtp.gmail.com with ESMTPSA id z26sm4464741qki.40.2020.11.12.05.40.05 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 12 Nov 2020 05:40:06 -0800 (PST) Date: Thu, 12 Nov 2020 08:40:05 -0500 From: Joel Fernandes To: Alexander Graf Cc: Nishanth Aravamudan , Julien Desfossez , Peter Zijlstra , Tim Chen , Vineeth Pillai , Aaron Lu , Aubrey Li , Thomas Glexiner , LKML , Ingo Molnar , Linus Torvalds , Frederic Weisbecker , Kees Cook , Greg Kerr , Phil Auld , Valentin Schneider , Mel Gorman , Pawan Gupta , Paolo Bonzini , vineeth@bitbyteword.org, Chen Yu , Christian Brauner , Agata Gruza , Antonio Gomez Iglesias , konrad.wilk@oracle.com, Dario Faggioli , Paul Turner , Steven Rostedt , Patrick Bellasi , =?utf-8?B?YmVuYmppYW5nKOiSi+W9qik=?= , Alexandre Chartre , James.Bottomley@hansenpartnership.com, OWeisse@umich.edu, Dhaval Giani , Junaid Shahid , Jesse Barnes , "Hyser,Chris" , Ben Segall , Josh Don , Hao Luo , "Anand K. Mistry" , Borislav Petkov , Daniel Bristot de Oliveira , Dietmar Eggemann , "H. Peter Anvin" , Ingo Molnar , Juri Lelli , Mel Gorman , Mike Rapoport , Tom Lendacky , Tony Luck , Vincent Guittot , "maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT)" Subject: Re: [RFC 1/2] x86/bugs: Disable coresched on hardware that does not need it Message-ID: <20201112134005.GA1549282@google.com> References: <20201111211011.1381848-1-joel@joelfernandes.org> <20201111211011.1381848-2-joel@joelfernandes.org> <76aa80c6-b797-f776-90fc-ef4585c41262@amazon.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <76aa80c6-b797-f776-90fc-ef4585c41262@amazon.com> Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Nov 11, 2020 at 11:29:37PM +0100, Alexander Graf wrote: > > > On 11.11.20 23:15, Joel Fernandes wrote: > > > > On Wed, Nov 11, 2020 at 5:13 PM Joel Fernandes wrote: > > > > > > On Wed, Nov 11, 2020 at 5:00 PM Alexander Graf wrote: > > > > On 11.11.20 22:14, Joel Fernandes wrote: > > > > > > Some hardware such as certain AMD variants don't have cross-HT MDS/L1TF > > > > > > issues. Detect this and don't enable core scheduling as it can > > > > > > needlessly slow the device done. > > > > > > > > > > > > diff --git a/arch/x86/kernel/cpu/bugs.c b/arch/x86/kernel/cpu/bugs.c > > > > > > index dece79e4d1e9..0e6e61e49b23 100644 > > > > > > --- a/arch/x86/kernel/cpu/bugs.c > > > > > > +++ b/arch/x86/kernel/cpu/bugs.c > > > > > > @@ -152,6 +152,14 @@ void __init check_bugs(void) > > > > > > #endif > > > > > > } > > > > > > > > > > > > +/* > > > > > > + * Do not need core scheduling if CPU does not have MDS/L1TF vulnerability. > > > > > > + */ > > > > > > +int arch_allow_core_sched(void) > > > > > > +{ > > > > > > + return boot_cpu_has_bug(X86_BUG_MDS) || boot_cpu_has_bug(X86_BUG_L1TF); > > > > > > > > Can we make this more generic and user settable, similar to the L1 cache > > > > flushing modes in KVM? > > > > > > > > I am not 100% convinced that there are no other thread sibling attacks > > > > possible without MDS and L1TF. If I'm paranoid, I want to still be able > > > > to force enable core scheduling. > > > > > > > > In addition, we are also using core scheduling as a poor man's mechanism > > > > to give customers consistent performance for virtual machine thread > > > > siblings. This is important irrespective of CPU bugs. In such a > > > > scenario, I want to force enable core scheduling. > > > > > > Ok, I can make it new kernel command line option with: > > > coresched=on > > > coresched=secure (only if HW has MDS/L1TF) > > > coresched=off > > > > Also, I would keep "secure" as the default. (And probably, we should > > modify the informational messages in sysfs to reflect this..) > > I agree that "secure" should be the default. Ok. > Can we also integrate into the "mitigations" kernel command line[1] for this? Sure, the integration into [1] sounds conceptually fine to me however it is not super straight forward. Like: What if user wants to force-enable core-scheduling for the usecase you mention, but still wants the cross-HT mitigation because they are only tagging VMs (as in your usecase) and not other tasks. Idk. The best thing to do could be to keep the "auto disable HT" controls and logic separate from the "coresched=on" logic and let the user choose. The exception being, coresched=secure means that on HW that does not have vulnerability, we will not activate the core scheduling. thanks, - Joel > Alex > > [1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/admin-guide/kernel-parameters.txt#n2839 > > > > Amazon Development Center Germany GmbH > Krausenstr. 38 > 10117 Berlin > Geschaeftsfuehrung: Christian Schlaeger, Jonathan Weiss > Eingetragen am Amtsgericht Charlottenburg unter HRB 149173 B > Sitz: Berlin > Ust-ID: DE 289 237 879 > >