From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mgamail.intel.com (mgamail.intel.com [192.198.163.15]) (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 517FF23C39A; Sat, 4 Apr 2026 03:50:01 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=192.198.163.15 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1775274603; cv=none; b=JnpPk7leDTAaV5u1J/EtFaxq5wXvJHxoa1/9IVsJVBqeolXeDPkP7sYoe6FBb+++ZSSY7Sg/Rd3NDb13n7tvcK9AjAUQVP/tTLlnqoJlbXxq//Dk9m5TlMN+Bb1Vh7lwg22MiCeS9QS7/ru0aewSpPswZPd1MDD1lK+ps2yrCMQ= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1775274603; c=relaxed/simple; bh=G8xvmblWSQNkLBTEI/Rr+0xm3IE4VSDw5eOz4xX4E/o=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=IiOtqMoTrUkxPEMGETuAsaeCP2wUG/FLrzhssskP2preaAfnTtXCJiwot0Llois8yVmjeUD0VDIzE9dtDNjfsVIfBspBaqvuwVAzkktLgnfqKvllWKCHsC1KdlXu1DgoOdavvAUCHDzdW9BnqjwdztsPqrVBK8+DSOaKUewGhZ0= 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=CgkeAZtg; arc=none smtp.client-ip=192.198.163.15 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="CgkeAZtg" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1775274602; x=1806810602; h=date:from:to:cc:subject:message-id:references: mime-version:content-transfer-encoding:in-reply-to; bh=G8xvmblWSQNkLBTEI/Rr+0xm3IE4VSDw5eOz4xX4E/o=; b=CgkeAZtg0w8ZFs2eqv2rOnQlT40DRN+98SS0rg0E2+VfvRTERWnviZTf f7gSIwwU/U/ifVuapRxey0ITJbP7fT7NmAPZHBjRL8e9pASajudDPggnm LzGIs+dqbkwOgb93xbR4mJ2UqGJkrHFCaSBctzGfLVZhk18sAp5+6Vw48 /iQwaHFsvK5nPkA7cAdRT2EIBYfTXEZht932uM7c+N9wRaBRVQEu4gV8W imo3aMuaay7I8WQmjxYTxavuhh/4U8TYvi4Nk2J3L6exBQ6yHgfCSQ0D5 JG5Mr1UoXizFpRIEXNbJxgJh7MoKOeGJbs/bEUjoiPKz0cth3oujtPYr0 w==; X-CSE-ConnectionGUID: tqdQLgeaSO+QbzVVVnLqoA== X-CSE-MsgGUID: r5iayE5WTSau5yzA1xD18w== X-IronPort-AV: E=McAfee;i="6800,10657,11748"; a="76445953" X-IronPort-AV: E=Sophos;i="6.23,159,1770624000"; d="scan'208";a="76445953" Received: from orviesa008.jf.intel.com ([10.64.159.148]) by fmvoesa109.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 03 Apr 2026 20:50:01 -0700 X-CSE-ConnectionGUID: /hjoufSMQX2cxDG39zfWEA== X-CSE-MsgGUID: zjRESZ50Q3SdWCVtQZrIZA== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.23,159,1770624000"; d="scan'208";a="227335088" Received: from guptapa-desk.jf.intel.com (HELO desk) ([10.165.239.46]) by orviesa008-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 03 Apr 2026 20:50:00 -0700 Date: Fri, 3 Apr 2026 20:49:54 -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: <20260404034954.t7iapenzvhdpagxp@desk> References: <20260403185236.sjgetnkha3o3a4d3@desk> <20260403213445.xzb4rxbfbg5un7li@desk> <20260403231608.zopnhnypdclzqlx7@desk> <20260403233329.fb2ppifgwm3um6ny@desk> <20260404002149.wtayv6a64vzuppgp@desk> Precedence: bulk X-Mailing-List: netdev@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: On Fri, Apr 03, 2026 at 07:21:02PM -0700, Jim Mattson wrote: > On Fri, Apr 3, 2026 at 5:22 PM Pawan Gupta > wrote: > > > > 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. > > Agreed. So, without any information to the contrary, VMs should assume > the long BHB clearing sequence is required. > > Returning to my earlier comment, the test should be: > > + if (cpu_feature_enabled(X86_FEATURE_BHI_CTRL) || > cpu_feature_enabled(X86_FEATURE_HYPERVISOR)) { > + bhb_seq_outer_loop = 12; > + bhb_seq_inner_loop = 7; > + } To be clear, my comment was for an OS that doesn't want BHI_DIS_S under-the-hood with virtual-SPEC_CTRL. Linux doesn't have that problem, hardware mitigation on Linux is perfectly okay. Without virtual-SPEC_CTRL, the problem set is limited to guests that migrate accross Alder Lake generation CPUs. As you mentioned the change in MAXPHYADDR makes it unlikely. With virtual-SPEC_CTRL support, guests that fall into the subset that migrate inspite of MAXPHYADDR change would also be mitigated. Then, on top of hardware mitigation, deploying the long sequence in the guest would incur a significant performance penalty for no good reason.