Received: by 2002:a05:6358:3188:b0:123:57c1:9b43 with SMTP id q8csp7718235rwd; Tue, 6 Jun 2023 15:23:21 -0700 (PDT) X-Google-Smtp-Source: ACHHUZ5q7sqxW4lIgfTrQwkfT0/kfeSNLw/1cPA/5KoZg/4/iPWf1KuNrcpw9pTR9A/VDl7YYvXR X-Received: by 2002:a05:6358:4f89:b0:127:f114:2d36 with SMTP id cg9-20020a0563584f8900b00127f1142d36mr1337164rwb.14.1686090201279; Tue, 06 Jun 2023 15:23:21 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1686090201; cv=none; d=google.com; s=arc-20160816; b=Y0Vq7awrCSx90kwA+SygGpD8/63QNx4URpvPEVX5NjTNWlFZN1DzpYs194rhXyw/NZ QsJawEVA1UdcV24KScPk/uIumOxlgfLzAeEI0fRibR5LITnFaisxkcg7q3HkdAfoC8bO scFSqEUl66w+BbaeOa/ZBTtSDXxRQE+oawnk0SefoxcRv/7kBWZM/79Hu3ytZU5B9Yks d+ghP57e1yI+cgZEiM5lTHEAuLlNIUn9zHaAF1XtMXi53C7InlmRHtWtEQrTrEKdh+S+ iYugu5KU92U7stjjGW6a0tPvnbuCyVPJyE7Z4nE6dQXAY5g7f40FHHZaYrLCTMORsxr1 pEyg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:from:subject:message-id:references :mime-version:in-reply-to:date:dkim-signature; bh=Xzo6RJjpAJUJYOMKM0Jqd4fwCnwZoeYzFNIgfiAwB3g=; b=nS1dJh7meUvVJe6eOxhZIvobhLi/zlm1W+tHVrQgdp94H/p1lvftH+CMryYK9Gwb3g ZJgSFHzEX7zmvN1pKQreP4zUDTRcGdx/bhLurz5xKrCu2attzTfi7z9G9oUXX+7A8eKW 650RvlkHKjShYUFWAPD4r5yRaFi+QuVinyJ6QNqzEtjtQSn6jX2c+BnEoATFbCEuN66S /spk/f+lRneXvoxs1tFL+nZgfGXPRss7eIvqNVBwBjpBYJimY5xQSq/d3cIEgFbYG+Yf NBN0ZyH5xdBgUN+WFdFh0V6Al7LEUFYE/qjVQVMrykrNQCwAI6V6GqQdKATK+tn0vZ+t DMMA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20221208 header.b=uR0RPAfU; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id az2-20020a17090b028200b0025378b5495bsi79123pjb.33.2023.06.06.15.23.08; Tue, 06 Jun 2023 15:23:21 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@google.com header.s=20221208 header.b=uR0RPAfU; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S239818AbjFFWDw (ORCPT + 99 others); Tue, 6 Jun 2023 18:03:52 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:50882 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S239830AbjFFWDm (ORCPT ); Tue, 6 Jun 2023 18:03:42 -0400 Received: from mail-yb1-xb49.google.com (mail-yb1-xb49.google.com [IPv6:2607:f8b0:4864:20::b49]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 18428172D for ; Tue, 6 Jun 2023 15:03:41 -0700 (PDT) Received: by mail-yb1-xb49.google.com with SMTP id 3f1490d57ef6-bacfa4eefd3so8997673276.3 for ; Tue, 06 Jun 2023 15:03:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20221208; t=1686089020; x=1688681020; h=cc:to:from:subject:message-id:references:mime-version:in-reply-to :date:from:to:cc:subject:date:message-id:reply-to; bh=Xzo6RJjpAJUJYOMKM0Jqd4fwCnwZoeYzFNIgfiAwB3g=; b=uR0RPAfUhKWNYrPJmlq4JqollYxJRzaaYHNTinGJzQ0UDAjZ1A99PmrbE9KlMMY0Xw AaCXh+SabY/hli0vgtnUweQMfUplnfSqzwqslXHnVfhTSxTVUxumC8ij8FoUggptlvhr 8Yo0vW1a2zkGUEbHjtIA204rq2AM+9fzVnCj7KLLJ5FioYEmzMn7tvP6tp1sqJy1DrlA sz+gS9g3PYN4g+XIkS3dnIqM3/awjguYS+WXoEsi3E9eIaKLghOb0Q6ZiInKpyHYH8S3 iMWwOoV8oQ7dgAGnQmzLb8f4UxYaWQas5wUQlmfVOKLbrnViDkN0s1VqdlmyyC95AP9A aixA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1686089020; x=1688681020; 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=Xzo6RJjpAJUJYOMKM0Jqd4fwCnwZoeYzFNIgfiAwB3g=; b=hBi2lC7dMM0KfKWr5637Ka39aN98nbhDKwyZLknuXVNZU4QMd+weabYWXKQxtoTvGi XHfc9o70q69PM8km0L86AhHCniAtl9+GC/pVNwKL+Tgr5iboufM4PbJGrZtyVuvqvJZL x0Z4pouTEizkE52jyvqny43TVRtYQgmkNV167YuduLxc55WQtIdyj9BeJp14tchCqFbY 0FYUBBKFisFdzh579kJCL6mImaQX25YUAJhN3dHZnN8eiwElVyCN3lu78xmTKwIA6dre a4bUKhJdI2XvZXHZuYKl7b7+ylIFidV8Xdp7Nl+7HEJDCW9Prp+dWpy/6xtYbbI+xHRT /m/g== X-Gm-Message-State: AC+VfDxzXydp2MjMNUkhGqjqjFvS3rEVkBgd/FUr1Q5w9p8UqgdeTPIF RJi9TsBVgfz8TQEza2j8NU41xnksFkw= X-Received: from zagreus.c.googlers.com ([fda3:e722:ac3:cc00:7f:e700:c0a8:5c37]) (user=seanjc job=sendgmr) by 2002:a25:2613:0:b0:bb4:f968:6c76 with SMTP id m19-20020a252613000000b00bb4f9686c76mr27336ybm.6.1686089020336; Tue, 06 Jun 2023 15:03:40 -0700 (PDT) Date: Tue, 6 Jun 2023 15:03:38 -0700 In-Reply-To: <20230606202557.GA71782@dev-dsk-luizcap-1d-37beaf15.us-east-1.amazon.com> Mime-Version: 1.0 References: <20230602005859.784190-1-seanjc@google.com> <20230606202557.GA71782@dev-dsk-luizcap-1d-37beaf15.us-east-1.amazon.com> Message-ID: Subject: Re: [PATCH] KVM: x86/mmu: Add "never" option to allow sticky disabling of nx_huge_pages From: Sean Christopherson To: Luiz Capitulino Cc: Paolo Bonzini , kvm@vger.kernel.org, linux-kernel@vger.kernel.org, Li RongQing , Yong He , Robert Hoo , Kai Huang Content-Type: text/plain; charset="us-ascii" X-Spam-Status: No, score=-9.6 required=5.0 tests=BAYES_00,DKIMWL_WL_MED, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_NONE, SPF_HELO_NONE,SPF_PASS,T_SCC_BODY_TEXT_LINE,USER_IN_DEF_DKIM_WL autolearn=ham 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 Tue, Jun 06, 2023, Luiz Capitulino wrote: > On Thu, Jun 01, 2023 at 05:58:59PM -0700, Sean Christopherson wrote: > However, why don't we make nx_huge_pages=never the default behavior if the > CPU is not vulnerable? Mainly because the mitigation has been around for 3.5 years, and there's a non-zero chance that making "never" the default could cause hiccups for unsuspecting users. If this were brand new code, I would definitely opt for "never" as the default. > If there are concerns about not being able to restart the worker thread, then > maybe we could make this a .config option? Eh, a Kconfig is unnecessarily complex, and wouldn't really change anything, e.g. for users in the know, it's just as easy to force a module param as it is to force a Kconfig, and to gain any benefit from the param being !never by default, the Kconfig would also have to be off by default. If "everyone" wants never to be the default, and Paolo doesn't object, I'd rather just tack on a patch to make that happen, and cross my fingers there's no fallout :-)