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=-5.8 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,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 ED2EAC433E6 for ; Thu, 25 Mar 2021 09:57:41 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id C1B7061A28 for ; Thu, 25 Mar 2021 09:57:41 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230079AbhCYJ5G (ORCPT ); Thu, 25 Mar 2021 05:57:06 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:48218 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229508AbhCYJ4d (ORCPT ); Thu, 25 Mar 2021 05:56:33 -0400 Received: from mail.skyhub.de (mail.skyhub.de [IPv6:2a01:4f8:190:11c2::b:1457]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 701FAC06174A; Thu, 25 Mar 2021 02:56:33 -0700 (PDT) Received: from zn.tnic (p200300ec2f0d5d00784c9f440731cfd1.dip0.t-ipconnect.de [IPv6:2003:ec:2f0d:5d00:784c:9f44:731:cfd1]) (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 57DD71EC0402; Thu, 25 Mar 2021 10:56:20 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alien8.de; s=dkim; t=1616666180; 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:in-reply-to:in-reply-to: references:references; bh=vZugkItkHUxPGcT3QUZAnpg+cYnx/DrzW+0wDfNLiPw=; b=UF6icgnek4xGi8in1o07q1ka9DdlhnOqBGKmkXqdcrrulx0OwsDEVflxSjOkdZW/9KOe47 Tjl68G+ZKPbAPGDOdsjUuiXm3rljUeybhO8iMS0W79NfMvzG4KmlAy5vAWH4PL46qcgMxs CA9fMH5T5ZSoSWr9EqhkAB/wFpWsPUU= Date: Thu, 25 Mar 2021 10:56:19 +0100 From: Borislav Petkov To: Hugh Dickins Cc: Babu Moger , Paolo Bonzini , Jim Mattson , Vitaly Kuznetsov , Wanpeng Li , kvm list , Joerg Roedel , the arch/x86 maintainers , LKML , Ingo Molnar , "H . Peter Anvin" , Thomas Gleixner , Makarand Sonare , Sean Christopherson Subject: Re: [PATCH v6 00/12] SVM cleanup and INVPCID feature support Message-ID: <20210325095619.GC31322@zn.tnic> References: <20210311203206.GF5829@zn.tnic> <2ca37e61-08db-3e47-f2b9-8a7de60757e6@amd.com> <20210311214013.GH5829@zn.tnic> <4a72f780-3797-229e-a938-6dc5b14bec8d@amd.com> <20210311235215.GI5829@zn.tnic> <20210324212139.GN5010@zn.tnic> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Mar 24, 2021 at 07:43:29PM -0700, Hugh Dickins wrote: > Right, after looking into it more, I completely agree with you: > the Kaiser series (in both 4.4-stable and 4.9-stable) was simply > wrong to lose that invlpg - fine in the kaiser case when we don't > enable Globals at all, but plain wrong in the !kaiser_enabled case. > One way or another, we have somehow got away with it for three years. Yeah, because there were no boxes with kaiser_enabled=0 *and* PCID which would set INVPCID_SINGLE. Before those, it would INVLPG in the !INVPCID_SINGLE case. Oh, btw, booting with "pci=on" "fixes" the issue too. And I tried reproducing this on an Intel box with "pti=off" but it booted fine so I'm probably missing some other aspect or triggering it there is harder/different due to TLB differences or whatnot. And Babu triggered the same issue on a AMD baremetal yesterday. > I do agree with Paolo that the PCID_ASID_KERN flush would be better > moved under the "if (kaiser_enabled)" now. Ok. > (And if this were ongoing development, I'd want to rewrite the > function altogether: but no, these old stable trees are not the place > for that.) Bah, it brought some very mixed memories, wading through that code after years. And yeah, people should stop using all these dead kernels already! So yeah, no, you don't want to clean up stuff there - let sleeping dogs lie. > Boris, may I leave both -stable fixes to you? > Let me know if you'd prefer me to clean up my mess. No worries, I'll take care of it. > Thanks a lot for tracking this down, Thanks for double-checking me so quickly, lemme whip up a patch. Thx. -- Regards/Gruss, Boris. https://people.kernel.org/tglx/notes-about-netiquette