From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mgamail.intel.com (mgamail.intel.com [192.198.163.19]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 359F414B977; Sat, 4 Apr 2026 00:21:58 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=192.198.163.19 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1775262120; cv=none; b=Uqj4vgPoor/5aGszZTW8K8k+U7fny5ksLG8dpIgs3McIYn7GJaGeG0O+ZEWDG/gkVqvbW0kyiI6RSRS9D9tSNBwywJvm7Hs8Cccl6KMHGoskypoTe+m8srj62auimkGuR1lgD0Nr1wrzkMzq7RnA2OPwsPH8eBX1bXHF0GUTDF8= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1775262120; c=relaxed/simple; bh=K4fQ8Le81jwgc4RkE1ZtctQHn7HYlHeLdMGdNNR+9jI=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=lVqH0PD/bAtZ+j/R5WADcLnS6o2qoCsHXThyZWyrxKSzqieMTtIHK6/WJcRnAjz0PaQY8BWcJYI+E7RXw/Z+MCM7B3Rd6Wpnv5O7Yuj8IcLI3enAaRLGPCQYPzqqJgLRnfnBu7W/P/Gd1mUiUFAyF5f9Eri4irFLtvQQM7ouHhs= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.intel.com; spf=pass smtp.mailfrom=linux.intel.com; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b=EizX9mIU; arc=none smtp.client-ip=192.198.163.19 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.intel.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linux.intel.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b="EizX9mIU" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1775262119; x=1806798119; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=K4fQ8Le81jwgc4RkE1ZtctQHn7HYlHeLdMGdNNR+9jI=; b=EizX9mIU+O95Qd0kn3+ufYfJ9tFv5bW44b383gGAYemtepzomUyF5K4y Gc/EtITakYaLCGMZdeR6/i3o5IcQkkl7x7GVk83jCc3QCGUt5YLLr7lNm S+zJSJt4tBFDggs6qubU+n2/AxTqvEDal5906Rh+Ls+0E4sCqFW1nghsD BKpDvtHRFPDZCtXb9u0wPkwaRqODbrN9A5fzsK0YTwqMnZNLGatKmTzDh xkVPwEeeMFJISHPaEmQ5pE2yB9WiM1pZRB1L8JjWtF1W0jrnYwL/Rj/RU JkcIuEttkBnMBBtaTqqvimWjmUcVmfN26CB7V81f2YkyVvxUCkix+KTac A==; X-CSE-ConnectionGUID: Iw4rPuOFR/mio6cRZbFRvw== X-CSE-MsgGUID: Y6r86Y3xQ76qprrJPqiyaQ== X-IronPort-AV: E=McAfee;i="6800,10657,11748"; a="75368382" X-IronPort-AV: E=Sophos;i="6.23,158,1770624000"; d="scan'208";a="75368382" Received: from orviesa006.jf.intel.com ([10.64.159.146]) by fmvoesa113.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 03 Apr 2026 17:21:58 -0700 X-CSE-ConnectionGUID: Gjpti8vKSNWPaml6JO+/3A== X-CSE-MsgGUID: Wal5rm5WRziZs8ottwMk1w== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.23,158,1770624000"; d="scan'208";a="226377012" Received: from guptapa-desk.jf.intel.com (HELO desk) ([10.165.239.46]) by orviesa006-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 03 Apr 2026 17:21:58 -0700 Date: Fri, 3 Apr 2026 17:21:49 -0700 From: Pawan Gupta To: Jim Mattson Cc: x86@kernel.org, Jon Kohler , Nikolay Borisov , "H. Peter Anvin" , Josh Poimboeuf , David Kaplan , Sean Christopherson , Borislav Petkov , Dave Hansen , Peter Zijlstra , Alexei Starovoitov , Daniel Borkmann , Andrii Nakryiko , KP Singh , Jiri Olsa , "David S. Miller" , David Laight , Andy Lutomirski , Thomas Gleixner , Ingo Molnar , David Ahern , Martin KaFai Lau , Eduard Zingerman , Song Liu , Yonghong Song , John Fastabend , Stanislav Fomichev , Hao Luo , Paolo Bonzini , Jonathan Corbet , linux-kernel@vger.kernel.org, kvm@vger.kernel.org, Asit Mallick , Tao Zhang , bpf@vger.kernel.org, netdev@vger.kernel.org, linux-doc@vger.kernel.org, chao.gao@intel.com Subject: Re: [PATCH v9 02/10] x86/bhi: Make clear_bhb_loop() effective on newer CPUs Message-ID: <20260404002149.wtayv6a64vzuppgp@desk> References: <20260402-vmscape-bhb-v9-2-94d16bc29774@linux.intel.com> <20260403185236.sjgetnkha3o3a4d3@desk> <20260403213445.xzb4rxbfbg5un7li@desk> <20260403231608.zopnhnypdclzqlx7@desk> <20260403233329.fb2ppifgwm3um6ny@desk> Precedence: bulk X-Mailing-List: linux-doc@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: On Fri, Apr 03, 2026 at 04:39:54PM -0700, Jim Mattson wrote: > > Since cloud providers have greater control over userspace, the decision to > > use BHI_DIS_S or not can be left to them. KVM would simply follow what it > > is asked to do by the userspace. > > I feel like we've gone over this before, but if userspace tells KVM > not to enable BHI_DIS_S, how do we inform Windows that it needs to do > the longer clearing sequence, despite the fact that the virtual CPU is > masquerading as Ice Lake? IMO, if an OS is allergic to a hardware mitigation, and is also aware that it is virtualized, it should default to a sw mitigation that works everywhere. > I don't think the virtual mitigation MSRs address that issue. Virtual mitigation MSRs are meant to inform the VMM about the guest mitigation. Even if there was a way to tell the guest that it needs to use a different mitigation, it seems unrealistic for a guest to change its mitigation post-migration.