Received: by 2002:a05:6358:489b:b0:bb:da1:e618 with SMTP id x27csp1733166rwn; Thu, 15 Sep 2022 23:04:54 -0700 (PDT) X-Google-Smtp-Source: AMsMyM4jeOTsYwqZtbqPuC+iquiu/LJq58wi+N2eFKPw3XkuRaigdCKiOy6qBh01bKpyP/LYBAle X-Received: by 2002:a17:907:2cd3:b0:77c:3e23:7bec with SMTP id hg19-20020a1709072cd300b0077c3e237becmr2514343ejc.380.1663308294119; Thu, 15 Sep 2022 23:04:54 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1663308294; cv=none; d=google.com; s=arc-20160816; b=cSKAnhKw1y00ufXonZA0V4p1d/4WUAoFe7nFP/dGB3sMLP68uHBUmUWBYk8pHJQuLz 9RRR6yFgQn2LLtviGB4vdJcKI3pmN2P3Yksr8+mwr5PlBpFNfC6GKQwKXlG2YZN6ld0E vgyK9/jt3QbmqZfQEVcH6Gb1xbPXcA/7VkSKQlda4m7N9Bb918lKOTQ2ikKhPoD1NV4h q6SwUTkl8k7xUkh9XxEI2LCxpq4il7B7oBA+nNy5wygSJPUKY88weTxXpKyXqQQfQikQ Uw20eBH49xI0jab4sVHG3DKarimEH4l/PKM9jn8zRqA5NxWr7LsbVb8g02Ub+yVZExrA dgRA== 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:mime-version:date :dkim-signature; bh=FfGEH82Goix2SWCi/zuywSATdy3fBWTr6hkvcyAr5AE=; b=hvvsTnvCxSxwkCMxz3j0Rh8rAYwhcDWH3HnY/e7PH1Ct/vF3Sx+jVUHM3mj25D/eeF ePlywdwLl7d38IVTPGFnV9lt90GuWtMbniWkWHGcTobc+FkcfeH8upEGQ8EHBJb/rCTJ LSUVuRI55ruXdk9Vb7T6JG3qjl76iS6CvqbqTUhKaaxcZVqtqo6Zzkt17B+pXtR/gdVu kFiQm+i6ZVoi0w2w2puyR+AOooPejROjU1b048YfvoomyynrAs6+kAruLl6JxDxdjx8W Q4VyvpYT1/ni2bfuIZ2ZACab+RcxfngdUz1iRR5Ffg0LkWLNlR5lhnAAJiiV0w8KE6iY 8Lkw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20210112 header.b=SaTCaJ0W; 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 c18-20020aa7df12000000b00451b381e080si1242520edy.517.2022.09.15.23.04.28; Thu, 15 Sep 2022 23:04:54 -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=20210112 header.b=SaTCaJ0W; 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 S229503AbiIPE64 (ORCPT + 99 others); Fri, 16 Sep 2022 00:58:56 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:57448 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229567AbiIPE6x (ORCPT ); Fri, 16 Sep 2022 00:58:53 -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 B0767A1D0C for ; Thu, 15 Sep 2022 21:58:52 -0700 (PDT) Received: by mail-yb1-xb49.google.com with SMTP id r62-20020a252b41000000b006af00577c42so13542979ybr.10 for ; Thu, 15 Sep 2022 21:58:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=cc:to:from:subject:message-id:mime-version:date:from:to:cc:subject :date; bh=FfGEH82Goix2SWCi/zuywSATdy3fBWTr6hkvcyAr5AE=; b=SaTCaJ0WrTR2A06woxfLg28wNkvqb43/YLMZaOcg0UMlHIJE+zrKK9a9YQ9Wpt7A+R 9Ow9HZtCjL5HyK1Lfrv7RAqVqHe9rRRmBQN9C1tuAJToZaK1uptkXli3R6wOf7a6FbcX VJiTkPSEGVyFZ0ovxouTzOSXlKSvv1X/IVBcIn/ZAmG6i52/kvc2Khp30cEBmPdfsdbc x73ILiVAQazDQUEGfoMFmhFk4xO4Go2SacKC4WfIDYJZU+CmhdoF9T/2DflpN9LKxTaN 8PWCncwWtFDY04ZkWI/nNcaV3v1Y1Vd0LGuG8I/QxXhmTHXHsbAVN1Qhx91xUc9fL1NC +2OQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:from:subject:message-id:mime-version:date:x-gm-message-state :from:to:cc:subject:date; bh=FfGEH82Goix2SWCi/zuywSATdy3fBWTr6hkvcyAr5AE=; b=T2yGDNenVdbqPCa77cM+Sg2zLZ3zMLTVaszraiZE/cftki/Ys2PhF0hgfPny2o8eLH xg9hP1HQVyAjBOjGkXCsl5ahPct1aYXTK5LW/0IJ1RTFVHltq1Xvi1yDg1TOZcxu6Rhi stc9FrT8f4gDbpfuW4gxAHmhcCEiiuOhHl4VyM5HVnr3MH4XZ94LvUR6b0dLvjt0b/Wt a5N0tLyv5eAPjm7N/C2LruMSB/9PVPvP+ydPqg/QJlC5mc4cfEz0yHahaAcnhmRKLQY1 3nhwuPJTM6uILPAzP905kcOnbmXGYbEU7o9NEOuvkGT3br63J1A/dQ71LwwEQFD6up93 VKYA== X-Gm-Message-State: ACrzQf1/Zrp7qsWObPqbHuQBtuD9Zv8KBXXIAklKHGEx/BFnAhSFy3m0 HRaTM5cDuhsI04jd5h0Km4kXrFoesO3nkg== X-Received: from loggerhead.c.googlers.com ([fda3:e722:ac3:cc00:24:72f4:c0a8:29a]) (user=jmattson job=sendgmr) by 2002:a05:6902:120f:b0:668:2228:9627 with SMTP id s15-20020a056902120f00b0066822289627mr3101150ybu.134.1663304331955; Thu, 15 Sep 2022 21:58:51 -0700 (PDT) Date: Thu, 15 Sep 2022 21:58:27 -0700 Mime-Version: 1.0 X-Mailer: git-send-email 2.37.3.968.ga6b4b080e4-goog Message-ID: <20220916045832.461395-1-jmattson@google.com> Subject: [PATCH 0/5] KVM: EFER.LMSLE cleanup From: Jim Mattson To: Avi Kivity , Babu Moger , Borislav Petkov , "Chang S. Bae" , Dave Hansen , "H. Peter Anvin" , Ingo Molnar , Joerg Roedel , Josh Poimboeuf , kvm@vger.kernel.org, linux-kernel@vger.kernel.org, Paolo Bonzini , Pawan Gupta , Peter Zijlstra , Sean Christopherson , Thomas Gleixner , Wyes Karny , x86@kernel.org Cc: Jim Mattson Content-Type: text/plain; charset="UTF-8" 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,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 KVM has never properly virtualized EFER.LMSLE. However, when the "nested" module parameter is set, KVM lets the guest set EFER.LMSLE. Ostensibly, this is so that SLES11 Xen 4.0 will boot as a nested hypervisor. KVM passes EFER.LMSLE to the hardware through the VMCB, so the setting works most of the time, but the KVM instruction emulator completely ignores the bit, so incorrect guest behavior is almost certainly assured. With Zen3, AMD has abandoned EFER.LMSLE. KVM still allows it, though, as long as "nested" is set. However, since the hardware doesn't support it, the next VMRUN after the emulated WRMSR will fail with "invalid VMCB." My preference would be to simply scrub all references to LMSLE from the Linux kernel, but I don't want to break any guests that rely in it (on hardware that supports it). So, here's a series to clean things up. I have not been successful in getting new macros into cpufeatures.h in the past, but I'm going to try again, because I am a glutton for punishment. Jim Mattson (5): x86/cpufeatures: Introduce X86_FEATURE_NO_LMSLE KVM: svm: Disallow EFER.LMSLE on hardware that doesn't support it KVM: x86: Report host's X86_FEATURE_NO_LMSLE in KVM_GET_SUPPORTED_CPUID KVM: x86: Enforce X86_FEATURE_NO_LMSLE in guest cpuid KVM: svm: Set X86_FEATURE_NO_LMSLE when !nested arch/x86/include/asm/cpufeatures.h | 1 + arch/x86/kvm/cpuid.c | 2 +- arch/x86/kvm/svm/svm.c | 6 +++++- arch/x86/kvm/x86.c | 3 +++ 4 files changed, 10 insertions(+), 2 deletions(-) -- 2.37.3.968.ga6b4b080e4-goog