Received: by 2002:a25:8b91:0:0:0:0:0 with SMTP id j17csp1050600ybl; Fri, 31 Jan 2020 13:05:46 -0800 (PST) X-Google-Smtp-Source: APXvYqx/XNJ2Qgyy4gX4qtX+HId46V8jFgCC3BW6Y07HX2J3IFm8IyV5F12ObFJOW49fTeYj6Xmf X-Received: by 2002:a05:6830:12d5:: with SMTP id a21mr9267810otq.296.1580504746455; Fri, 31 Jan 2020 13:05:46 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1580504746; cv=none; d=google.com; s=arc-20160816; b=hFO1+ZZx9TyHQxX8Q878ZlPisVBT5pUuoC/QgYJqa2iyzaDSJ5NuIZfHBol8eOFled TaSTBpVJzKr9MUP6VrozUYEZMsJqAnVum6xqOtkIEy5/+kZMyGkEZ0BEzM7YecSW0orQ huJe3O3NtXTCuxvXdVrH7GaRoUeR3nEDlhcAtR4Gxo/HQdeivWskKGK8/dVIipYblO/R j/Zpu9xGcZGnTWoqIvjCb2swWIRc7a+lQUvcwzO8CTC5gRMdXXeD+FrI5lu5RMIc/dC0 hT0RVyh4oIp7D2AWgODUHQto0NHgpFmu1ABGMk+/JiWUjcX3Q3Mz9MGgpo+dTXvSvAly EgIw== 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=qT6dC568RdrQrL7YVdlXMSe2VM/X06I+Nm1IDvcDYhI=; b=mJQMZRlyt4Ddh68vIkWaDyCa1mJ0zdFGlCEE1oHtzTN+Hc2YeSSjqasagTnb5J4FzA OFb2SbBlRtUdGSNSKiDTL4GzDti5SzPeofNV8WtK+xm3Rsd61caPKNFy9c6z7ye0zIsV m9v0EbC8j7HWPmUjcypK8FSNrB0FTtjenlphL+RG6GrTIxPmryiej9M0iLNo0k9TZEQn 4WTh8/ZtUGA8V8nHb8rcIx1Gwq9v/1hsLSW9KUdB0ousTWQZcRgWq0ts+qfqs0V4hCwn lEqKdET/2RZBcumIseou7KPnNnj/rMjbWb9iWiLZqpkRx7qP4/p9FEmr4/sdvNfy1tq4 WFVg== 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 v26si5670677otj.0.2020.01.31.13.05.32; Fri, 31 Jan 2020 13:05:46 -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 S1726475AbgAaVEZ (ORCPT + 99 others); Fri, 31 Jan 2020 16:04:25 -0500 Received: from mga12.intel.com ([192.55.52.136]:57876 "EHLO mga12.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726102AbgAaVEZ (ORCPT ); Fri, 31 Jan 2020 16:04:25 -0500 X-Amp-Result: UNSCANNABLE X-Amp-File-Uploaded: False Received: from orsmga007.jf.intel.com ([10.7.209.58]) by fmsmga106.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 31 Jan 2020 13:04:24 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.70,387,1574150400"; d="scan'208";a="218725860" Received: from sjchrist-coffee.jf.intel.com (HELO linux.intel.com) ([10.54.74.202]) by orsmga007.jf.intel.com with ESMTP; 31 Jan 2020 13:04:24 -0800 Date: Fri, 31 Jan 2020 13:04:24 -0800 From: Sean Christopherson To: Andy Lutomirski Cc: Xiaoyao Li , Thomas Gleixner , Ingo Molnar , Borislav Petkov , "H. Peter Anvin" , Paolo Bonzini , x86@kernel.org, linux-kernel@vger.kernel.org, kvm@vger.kernel.org Subject: Re: [PATCH 2/2] KVM: VMX: Extend VMX's #AC handding Message-ID: <20200131210424.GG18946@linux.intel.com> References: <20200131201743.GE18946@linux.intel.com> <5CD544A4-291A-47A1-80D1-F77FE0444925@amacapital.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5CD544A4-291A-47A1-80D1-F77FE0444925@amacapital.net> 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 Fri, Jan 31, 2020 at 12:57:51PM -0800, Andy Lutomirski wrote: > > > On Jan 31, 2020, at 12:18 PM, Sean Christopherson wrote: > > > > This is essentially what I proposed a while back. KVM would allow enabling > > split-lock #AC in the guest if and only if SMT is disabled or the enable bit > > is per-thread, *or* the host is in "warn" mode (can live with split-lock #AC > > being randomly disabled/enabled) and userspace has communicated to KVM that > > it is pinning vCPUs. > > How about covering the actual sensible case: host is set to fatal? In this > mode, the guest gets split lock detection whether it wants it or not. How do > we communicate this to the guest? KVM doesn't advertise split-lock #AC to the guest and returns -EFAULT to the userspace VMM if the guest triggers a split-lock #AC. Effectively the same behavior as any other userspace process, just that KVM explicitly returns -EFAULT instead of the process getting a SIGBUS.