Received-SPF: pass (google.com: domain of linux-kernel+bounces-141245-linux.lists.archive=gmail.com@vger.kernel.org designates 139.178.88.99 as permitted sender) client-ip=139.178.88.99;
Date: Thu, 11 Apr 2024 23:56:39 +0800
From: Chao Gao <chao.gao@intel.com>
To: Paolo Bonzini <pbonzini@redhat.com>
CC: Alexandre Chartre <alexandre.chartre@oracle.com>, Andrew Cooper
	<andrew.cooper3@citrix.com>, <x86@kernel.org>, <kvm@vger.kernel.org>,
	<linux-kernel@vger.kernel.org>, <daniel.sneddon@linux.intel.com>,
	<pawan.kumar.gupta@linux.intel.com>, <tglx@linutronix.de>,
	<konrad.wilk@oracle.com>, <peterz@infradead.org>,
	<gregkh@linuxfoundation.org>, <seanjc@google.com>,
	<dave.hansen@linux.intel.com>, <nik.borisov@suse.com>, <kpsingh@kernel.org>,
	<longman@redhat.com>, <bp@alien8.de>
Subject: Re: [PATCH] KVM: x86: Set BHI_NO in guest when host is not affected
 by BHI
Message-ID: <ZhgIN4LIu2K5vf5y@chao-email>
References: <20240411072445.522731-1-alexandre.chartre@oracle.com>
 <7f1faa48-6252-4409-aefc-2ed2f38fb1c3@citrix.com>
 <caa51938-c587-4403-a9cd-16e8b585bc13@oracle.com>
 <CABgObfai1TCs6pNAP4i0x99qAjXTczJ4uLHiivNV7QGoah1pVg@mail.gmail.com>
 <abbaeb7c-a0d3-4b2d-8632-d32025b165d7@oracle.com>
 <2afb20af-d42e-4535-a660-0194de1d0099@citrix.com>
 <ff3cf105-ef2a-426c-ba9b-00fb5c2559c7@oracle.com>
 <CABgObfZU_uLAPzDV--n67H3Hq6OKxUO=FQa2MH3CjdgTQR8pJg@mail.gmail.com>
 <99ad2011-58b7-42c8-9ee5-af598c76a732@oracle.com>
 <CABgObfa_mkk-c3NZ623WzYDxw59NcYB_tEQ8tFX4CECHW3JxQQ@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <CABgObfa_mkk-c3NZ623WzYDxw59NcYB_tEQ8tFX4CECHW3JxQQ@mail.gmail.com>
Precedence: bulk
MIME-Version: 1.0
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?MXpDZm1LR2dhcEM2VVp5WUFvSUVBcy9FNng2cFdud1BZSWF1MU9SOGJXVmRO?=
 =?utf-8?B?a1RiN25HMGdyK3JYVDlkbm4rbXVVVWxDTFBQQnkyeDRQaXhXdldMRHJFeWRa?=
 =?utf-8?B?NnZJREpIMVFzMFA0aGE3Y054YlYzM2F3MVVJOTlUMTBPbVRrdURSNVo2QnA3?=
 =?utf-8?B?Rm1CTUR4MjV4RG93VzZObUlyUjJLQml3OEZjWGZIYXNkT01BenkraGt5ZVY0?=
 =?utf-8?B?a1ZsdThxNVkzMEo5TTNjV3JkT3VDSUZYMlhzYWlseDdsbUhSWmkwZkY0Umhy?=
 =?utf-8?B?UHFHcTBhU2FjdUJSdHczaWVRUlNxSTQydmRGTlhiYkdaeWtpdnVscGxpOFFs?=
 =?utf-8?B?UmJSR3YyS3EySnRENmtYeTZ5eWl4eVBOMXhPUVhEM3VQdnZGY1pSNW5aWGkz?=
 =?utf-8?B?T0FoV29vNEN6eGlvMjh1czduTUxsem5aNDgxMVNoeE1ocWFYeFd5TFNtMDFB?=
 =?utf-8?B?UEZUeHdvZXdkTEtFaXd5SDNkTGgrNTNsYnRoem0rWThBclU1UEVOSUQvZjhL?=
 =?utf-8?B?U1RFUStqSUZwTDdwcXc1d1M2UThNeU8vY2Y1REtqbFUyc0JpcGNUL3o5K2Jo?=
 =?utf-8?B?MzkxNkh6eHc1a0g4U2U1ZnFxNEE1L3hRYnR6MU5hU0kwNkFCVTZmdGNzaU5T?=
 =?utf-8?B?NGZSemlUY1EyOUtvWW1UbzBNRzJQcy9XZlc1eFV6SHdpUjV5ZDNLU3dETzZr?=
 =?utf-8?B?TWo4a3JKVWdadkM4VlV5dnQ5ZTJ3ZXVCMmFwVUpwZ1gxVVJSYXlSR2hNWDhK?=
 =?utf-8?B?bW16eTF3amtLQk9WWTJiZTYrUXQ2RFlJQkh2UkdJOWM1bFhqTGlCRlljV2N0?=
 =?utf-8?B?R2VwQ09XaUZpdi9NMDZvQ3FVbHJVNHhXRjFvdlVNSVpMYnVPUldBYVF3aFp6?=
 =?utf-8?B?dFZzZ0dBa2VMS3l5cS9VeEE1cmlPRzBUQ0R2SlNwNzlDL2R0MGY5MUN5czZ4?=
 =?utf-8?B?WEQ3SGo2eXl6bzNzTml4UDJMNmdxSHluMlA3c0c4UDJ5Wi85Zk5PeGFyT2tG?=
 =?utf-8?B?cUpZK0UyUWdnNzNwa3JTRlp6UTZjeUQyMDYrRlV6bGkwRFpPSDUrWHp3eWFr?=
 =?utf-8?B?eFJINC8vY1Z0WGZPS3UvdUo5Q2o5WFl2aUJuUHMweHFnTGROaG50bUVUYTk4?=
 =?utf-8?B?dWRCNWVFbElNM1h0d1NjUkdsaFB4SzhuNEJ2eE0zSGZJUU9EQ2N6TDZaSFFW?=
 =?utf-8?B?SXE5R0tQU3RZdklscnZ3L0xpZ291YVk4cDFUTHVlUGJxUDNScWgzNkFJaTBP?=
 =?utf-8?B?aHFPVTk0SG9LbXpOaElXdnlDZDc3cGN6UncxVmludzFoYytpbDFYL2l3djFT?=
 =?utf-8?B?aTcrVmhkOXF6Sm0wRW1iOE93bUltNXRoL0dRK2Z2NU9pc3N2L3JNbEVCUWNq?=
 =?utf-8?B?OWdzY2FWTnhPUzZtNFZaajc3YlpYZ0VRS1hXeEZBNWt5ZHpuRGg1RUh0UGlP?=
 =?utf-8?B?QitHTCtCTmRPVmxBYW9tS0plbzBsYlNVOWtFTFN0V3dhYmRMdzEzT1N5WjlU?=
 =?utf-8?B?ZjdDS0d1SXdHc1I0cDdGQjVxeEdaeGNmRFowR09jUWtDSFdKdTEyNnFDYTRP?=
 =?utf-8?B?UUt2TU1YYzZ2em5tMStaUytwTEVVNmJ5YjFRQ01HWXd1YUhNOUhPeHB6ZzNP?=
 =?utf-8?B?OGNuRVNRWUNZVHdLd1c4WDZ1ZHhFNlVSbmx6UC91OVZSMDh5ZFdKQm9qSmlU?=
 =?utf-8?B?YXRIVXFWOUVBbDVLbHdlMmVRRHFMZjh6WlpFUDk0NEpKalVGaFcyQVo3NmEv?=
 =?utf-8?B?bWFhRExvMkt2anFKS3pkSXJGQXlDVU1KVVY1L2RPeWExRVJHZ3BIYU1ranpy?=
 =?utf-8?B?VGlVdnFXank1NEhzVWlhTXdMZ2hDaUNiOHR5RHpCVS9BWFphcGhqdmswZk1N?=
 =?utf-8?B?NkJIbS9ZcS9naWlyaDF0WldtUGI2S0ZuOVhTaFRJUmJxSXRweC9jMmdqSVVO?=
 =?utf-8?B?QWEwNTJxUjhJd1AxUXdSQ21aZzFVbHdwQ1QvOXFMcjQ1MkRBOUwvZ0xEY0lQ?=
 =?utf-8?B?Zi9DK29YTmc2eWJpZFNCOVQrVlpzbDJtY0plQmkyaXkwL2NkVDhLdUFWUzZr?=
 =?utf-8?B?OHNNb3Fjb0w1Q09DRnVsZll6enNYY2JqZzVKNkdVQWJaVkp3ZEZBU0lCZWJR?=
 =?utf-8?Q?wpfMyNm/aw87derUZUOhDe4kp?=
X-MS-Exchange-CrossTenant-Network-Message-Id: 91a6cf0c-fecd-4cd4-4fce-08dc5a4000d0
X-MS-Exchange-CrossTenant-AuthSource: CH3PR11MB8660.namprd11.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 11 Apr 2024 15:56:51.9293
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 46c98d88-e344-4ed4-8496-4ed7712e255d
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: csiNYEEtwndJlKhssY8CsQ7qPdPFi6iOZEfp00opuiBEEH516xpW1Q/qeVd1KqMHgKsLv/vb9ClO0W4VufPX/A==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DS0PR11MB8665
X-OriginatorOrg: intel.com

On Thu, Apr 11, 2024 at 05:20:30PM +0200, Paolo Bonzini wrote:
>On Thu, Apr 11, 2024 at 5:13 PM Alexandre Chartre
><alexandre.chartre@oracle.com> wrote:
>> I think that Andrew's concern is that if there is no eIBRS on the host then
>> we do not set X86_BUG_BHI on the host because we know the kernel which is
>> running and this kernel has some mitigations (other than the explicit BHI
>> mitigations) and these mitigations are enough to prevent BHI. But still
>> the cpu is affected by BHI.
>
>Hmm, then I'm confused. It's what I wrote before: "The (Linux or
>otherwise) guest will make its own determinations as to whether BHI
>mitigations are necessary. If the guest uses eIBRS, it will run with
>mitigations" but you said machines without eIBRS are fine.
>
>If instead they are only fine _with Linux_, then yeah we cannot set
>BHI_NO in general. What we can do is define a new bit that is in the
>KVM leaves. The new bit is effectively !eIBRS, except that it is
>defined in such a way that, in a mixed migration pool, both eIBRS and
>the new bit will be 0.

This looks a good solution.

We can also introduce a new bit indicating the effectiveness of the short
BHB-clearing sequence. KVM advertises this bit for all pre-SPR/ADL parts.
Only if the bit is 1, guests will use the short BHB-clearing sequence.
Otherwise guests should use the long sequence. In a mixed migration pool,
the VMM shouldn't expose the bit to guests.

>
>Paolo
>
>