Received: by 2002:a25:8b91:0:0:0:0:0 with SMTP id j17csp4107288ybl; Mon, 3 Feb 2020 12:43:23 -0800 (PST) X-Google-Smtp-Source: APXvYqxQ2IZgaxXPJHKL/aR+6e9OL8nSi8Kf7A9DVzJ4j+Rz2GGp1yjmCvXKL+mT+rKGN1yXPvhM X-Received: by 2002:aca:f2c5:: with SMTP id q188mr644744oih.113.1580762603022; Mon, 03 Feb 2020 12:43:23 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1580762603; cv=none; d=google.com; s=arc-20160816; b=x0e2r3NpsENoUMtSIrnKk38OXq+2//0B1DFtZhzicKHo3qKMAaG8RB+LL09ZVwnQJc EEPN9KyiURtMjJ5EBEdwBEDBN0i4gbbmGJo4CRAKndDpheshxTky+44vuHpb+ZL9juvl /aCJeNR29fKp608HiDHrYXVY3SkT57gmeOTQ8+6EJDvfO/felcj0bC+CInFZfx4uQjeK WWbmnQwydfwPxd+TmYRnseyL7Vm2ZXdOtbgou46yimiMj4LqRhUeIrWVircozDD0sPzd lxAdYqQndu1J0x2aJrMXceaJOAc0LuoWEL6NudhZJIJPu3HqlQDuFnVzroDdscZuPD2+ lxBA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date; bh=13ohSA0Ksqbrr/eC6pHohCzmB3hu3ZKMtm7QR7ci+XU=; b=rM9qQ4FWxjJ7dfok25aCAbiAVKvSHD3vXF4MkQenWZ3rFtYutcgQ7cImfEoCZ6kPrb DK2HUvadEGPGNuqkcNj9WFuL1O+inz6BITx22NjR4dEgbO+LH7SQYgR69BZfyTGbnh3o ut2ucE50djgoeU/8N1xUhgs1EgqJaST1/pPj8T7dUc28Ui3X6taFqNimITVxPRdhoN3V SmA5OjDvVHu8DP/ikVXrIFt6NhEjGbqAtL7k/JMkY1tYKvf+hcQ6Aipulz95Ipw1+fGR KrAMPYInyrf1qygv+QJX11T8Ewydab1DnPEhSwTwW42HhetrrtllGQ0EK6VmSkRPia5z yTDg== 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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id e22si9005751oiy.124.2020.02.03.12.43.10; Mon, 03 Feb 2020 12:43:23 -0800 (PST) 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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727063AbgBCUl4 (ORCPT + 99 others); Mon, 3 Feb 2020 15:41:56 -0500 Received: from mga02.intel.com ([134.134.136.20]:58355 "EHLO mga02.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726325AbgBCUl4 (ORCPT ); Mon, 3 Feb 2020 15:41:56 -0500 X-Amp-Result: UNSCANNABLE X-Amp-File-Uploaded: False Received: from orsmga001.jf.intel.com ([10.7.209.18]) by orsmga101.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 03 Feb 2020 12:41:55 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.70,398,1574150400"; d="scan'208";a="310831201" Received: from sjchrist-coffee.jf.intel.com (HELO linux.intel.com) ([10.54.74.202]) by orsmga001.jf.intel.com with ESMTP; 03 Feb 2020 12:41:55 -0800 Date: Mon, 3 Feb 2020 12:41:55 -0800 From: Sean Christopherson To: "Luck, Tony" Cc: Thomas Gleixner , Mark D Rustad , Arvind Sankar , Peter Zijlstra , Ingo Molnar , "Yu, Fenghua" , Ingo Molnar , Borislav Petkov , H Peter Anvin , "Raj, Ashok" , "Shankar, Ravi V" , linux-kernel , x86 Subject: Re: [PATCH v17] x86/split_lock: Enable split lock detection by kernel Message-ID: <20200203204155.GE19638@linux.intel.com> References: <4E95BFAA-A115-4159-AA4F-6AAB548C6E6C@gmail.com> <8CC9FBA7-D464-4E58-8912-3E14A751D243@gmail.com> <20200126200535.GB30377@agluck-desk2.amr.corp.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200126200535.GB30377@agluck-desk2.amr.corp.intel.com> User-Agent: Mutt/1.5.24 (2015-08-30) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sun, Jan 26, 2020 at 12:05:35PM -0800, Luck, Tony wrote: > +/* > + * Locking is not required at the moment because only bit 29 of this > + * MSR is implemented and locking would not prevent that the operation > + * of one thread is immediately undone by the sibling thread. > + * Use the "safe" versions of rdmsr/wrmsr here because although code > + * checks CPUID and MSR bits to make sure the TEST_CTRL MSR should > + * exist, there may be glitches in virtualization that leave a guest > + * with an incorrect view of real h/w capabilities. > + */ > +static bool __sld_msr_set(bool on) > +{ > + u64 test_ctrl_val; > + > + if (rdmsrl_safe(MSR_TEST_CTRL, &test_ctrl_val)) > + return false; How about caching the MSR value on a per-{cpu/core} basis at boot to avoid the RDMSR when switching to/from from a misbehaving tasks? E.g. to avoid penalizing well-behaved tasks any more than necessary. We've likely got bigger issues if MSR_TEST_CTL is being written by BIOS at runtime, even if the writes were limited to synchronous calls from the kernel. Probably makes sense to split the MSR's init sequence and runtime sequence, e.g. to also use an unsafe wrmsrl() at runtime so that an unexpected #GP generates a WARN. > + > + if (on) > + test_ctrl_val |= MSR_TEST_CTRL_SPLIT_LOCK_DETECT; > + else > + test_ctrl_val &= ~MSR_TEST_CTRL_SPLIT_LOCK_DETECT; > + > + return !wrmsrl_safe(MSR_TEST_CTRL, test_ctrl_val); > +}