On Mon, Jan 31, 2022 at 11:15:09AM +0000, Andrew Cooper wrote: > On 31/01/2022 09:41, Roger Pau Monné wrote: > > On Fri, Jan 28, 2022 at 01:29:19PM +0000, Andrew Cooper wrote: > >> This is a statement of hardware behaviour, and not related to controls for > >> the > >> guest kernel to use. Pass it straight through from hardware. > >> > > Not really related to this patch per se, but I think we should expose > > AMD_SSBD unconditionally for SPEC_CTRL (and VIRT_SSBD for > > VIRT_SPEC_CTRL when supported) in the max policies and implement them > > as noop for compatibility reasons? > > > > I would expect CPUs exposing SSB_NO to drop AMD_SSBD and VIRT_SSBD at > > some point. > > Why? SSBD is an architectural feature. It's far more likely to turn > into a no-op on SSB_NO hardware, than to disappear, especially as the > MSR is exposed to guests. > > VIRT_SSBD is only offered by hypervisors, and should only be offered > when there are members in the migration pool without MSR_SPEC_CTRL.
But we should also offer VIRT_SSBD in the max policy if the hardware reports SSB_NO, because then it's a no-op and would allow for migration from boxes where we do offer VIRT_SSBD. Thanks, Roger.
