Received: by 2002:a25:d7c1:0:0:0:0:0 with SMTP id o184csp884195ybg; Fri, 18 Oct 2019 08:46:32 -0700 (PDT) X-Google-Smtp-Source: APXvYqxbwy7qRlNWvE4uA0KlOlNhgoXMI89JK4tU0QYQpYuGhnL6xkYqt6HzGXDefHOMXoyeTnDb X-Received: by 2002:a50:ed84:: with SMTP id h4mr10125148edr.124.1571413592640; Fri, 18 Oct 2019 08:46:32 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1571413592; cv=none; d=google.com; s=arc-20160816; b=jbwMKV6ZyO79gDPf1SkpmOWtS++p7RzeLILKIDmkaqykJuneBH2EpRvnZMGRpciXJc yhOSKUcDdMt+9fDezSNNa1mgh+aGJaDUnAbYI/SrBmf4Lqin3LXJTr8016zRnuNNMSow rN5XhxK0yduFVTuUsvgzCx+HPNeXmZsREPGZcN3ftDpjpCQE9TzkQpWWGw8rCkrbzDk0 JHqf1SVG5nAtdqtFX2+wVMavWUFwBfiewesMu72l6nFAiaifKddyI2BetP//ncVGWqrT DY+W0jqfj8JOuAzKy84oueOQIh4xqwSFXGVYACcgYnXzwGhax9/3K9kS5seMJC4ScQ71 uZnQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:mime-version:user-agent:references :message-id:in-reply-to:subject:cc:to:from:date; bh=uLzVq/l1bDLqqIchdmpiuyPkUz/eqJD7uRnEJCqGD4Q=; b=C417edBWyK1vZXVtnecF28oKQMXm9irAsxsMqbJg9245xS7qQLivemIZne5W6GJ+BT T0wAwbEvO4QgBBBQRpdBdwmp2LXJ6iXazCPZgHtXdOZqYk/MtDygcRXQmKurGJIcUARP hVoB4Ww8vF5q3KbrLWjUJxrAvxF+Hjn3mg3/InjfMznhO8U8GCQxkEw4AxxZXeKWoysC 0+6+2vvL6J5D7pZs1kMwXt6bkKrdt+2bv7xkvEUvaO96+AKyPuuWTFAlckkT32coR/qw PyyoW+kCN11rxVLT1KAfKga2EMX+OOoHrpxxIQyhctwct68bpw8EoXvEXoHnTsy3Ot56 d3zA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id gl26si3723902ejb.17.2019.10.18.08.46.09; Fri, 18 Oct 2019 08:46:32 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2393944AbfJQMaC (ORCPT + 99 others); Thu, 17 Oct 2019 08:30:02 -0400 Received: from Galois.linutronix.de ([193.142.43.55]:52857 "EHLO Galois.linutronix.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728190AbfJQMaC (ORCPT ); Thu, 17 Oct 2019 08:30:02 -0400 Received: from [5.158.153.52] (helo=nanos.tec.linutronix.de) by Galois.linutronix.de with esmtpsa (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from ) id 1iL4uY-0007rm-1f; Thu, 17 Oct 2019 14:29:46 +0200 Date: Thu, 17 Oct 2019 14:29:45 +0200 (CEST) From: Thomas Gleixner To: Paolo Bonzini cc: Xiaoyao Li , Sean Christopherson , Fenghua Yu , Ingo Molnar , Borislav Petkov , H Peter Anvin , Peter Zijlstra , Andrew Morton , Dave Hansen , Radim Krcmar , Ashok Raj , Tony Luck , Dan Williams , Sai Praneeth Prakhya , Ravi V Shankar , linux-kernel , x86 , kvm@vger.kernel.org Subject: [RFD] x86/split_lock: Request to Intel In-Reply-To: Message-ID: References: <1560897679-228028-1-git-send-email-fenghua.yu@intel.com> <1560897679-228028-10-git-send-email-fenghua.yu@intel.com> <20190626203637.GC245468@romley-ivt3.sc.intel.com> <20190925180931.GG31852@linux.intel.com> <3ec328dc-2763-9da5-28d6-e28970262c58@redhat.com> <57f40083-9063-5d41-f06d-fa1ae4c78ec6@redhat.com> <8808c9ac-0906-5eec-a31f-27cbec778f9c@intel.com> User-Agent: Alpine 2.21 (DEB 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org The more I look at this trainwreck, the less interested I am in merging any of this at all. The fact that it took Intel more than a year to figure out that the MSR is per core and not per thread is yet another proof that this industry just works by pure chance. There is a simple way out of this misery: Intel issues a microcode update which does: 1) Convert the OR logic of the AC enable bit in the TEST_CTRL MSR to AND logic, i.e. when one thread disables AC it's automatically disabled on the core. Alternatively it supresses the #AC when the current thread has it disabled. 2) Provide a separate bit which indicates that the AC enable logic is actually AND based or that #AC is supressed when the current thread has it disabled. Which way I don't really care as long as it makes sense. If that's not going to happen, then we just bury the whole thing and put it on hold until a sane implementation of that functionality surfaces in silicon some day in the not so foreseeable future. Seriously, this makes only sense when it's by default enabled and not rendered useless by VIRT. Otherwise we never get any reports and none of the issues are going to be fixed. Thanks, tglx