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=-1.3 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, HK_RANDOM_FROM,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 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 E0FFDCA9EA0 for ; Fri, 18 Oct 2019 10:20:53 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id C399C222CD for ; Fri, 18 Oct 2019 10:20:53 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2394044AbfJRKUu (ORCPT ); Fri, 18 Oct 2019 06:20:50 -0400 Received: from mga04.intel.com ([192.55.52.120]:24969 "EHLO mga04.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2387890AbfJRKUu (ORCPT ); Fri, 18 Oct 2019 06:20:50 -0400 X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga005.jf.intel.com ([10.7.209.41]) by fmsmga104.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 18 Oct 2019 03:20:50 -0700 X-IronPort-AV: E=Sophos;i="5.67,311,1566889200"; d="scan'208";a="371425922" Received: from xiaoyaol-mobl.ccr.corp.intel.com (HELO [10.239.13.123]) ([10.239.13.123]) by orsmga005-auth.jf.intel.com with ESMTP/TLS/AES256-SHA; 18 Oct 2019 03:20:45 -0700 Subject: Re: [RFD] x86/split_lock: Request to Intel To: Thomas Gleixner Cc: Paolo Bonzini , 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 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> <5da90713-9a0d-6466-64f7-db435ba07dbe@intel.com> From: Xiaoyao Li Message-ID: <763bb046-e016-9440-55c4-33438e35e436@intel.com> Date: Fri, 18 Oct 2019 18:20:44 +0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Sender: kvm-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: kvm@vger.kernel.org On 10/18/2019 5:02 PM, Thomas Gleixner wrote: > On Fri, 18 Oct 2019, Xiaoyao Li wrote: >> On 10/17/2019 8:29 PM, Thomas Gleixner wrote: >>> 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. >>> >> >> Whether it's per-core or per-thread doesn't affect much how we implement for >> host/native. > > How useful. OK. IIUC. We can agree on the use model of native like below: We enable #AC on all cores/threads to detect split lock. -If user space causes #AC, sending SIGBUS to it. -If kernel causes #AC, we globally disable #AC on all cores/threads, letting kernel go on working and WARN. (only disabling #AC on the thread generates it just doesn't help, since the buggy kernel code is possible to run on any threads and thus disabling #AC on all of them) As described above, either enabled globally or disabled globally, so whether it's per-core or per-thread really doesn't matter >> And also, no matter it's per-core or per-thread, we always can do something in >> VIRT. > > It matters a lot. If it would be per thread then we would not have this > discussion at all. Indeed, it's the fact that the control MSR bit is per-core to cause this discussion. But the per-core scope only makes this feature difficult or impossible to be virtualized. We could make the decision to not expose it to guest to avoid the really bad thing. However, even we don't expose this feature to guest and don't virtualize it, the below problem always here. If you think it's not a problem and acceptable to add an option to let KVM disable host's #AC detection, we can just make it this way. And then we can design the virtualizaion part without any change to native design at all. >> Maybe what matters is below. >> >>> 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. >>> >> >> For VIRT, it doesn't want old guest to be killed due to #AC. But for native, >> it doesn't want VIRT to disable the #AC detection >> >> I think it's just about the default behavior that whether to disable the >> host's #AC detection or kill the guest (SIGBUS or something else) once there >> is an split-lock #AC in guest. >> >> So we can provide CONFIG option to set the default behavior and module >> parameter to let KVM set/change the default behavior. > > Care to read through the whole discussion and figure out WHY it's not that > simple? > > Thanks, > > tglx >