[MODERATED] Re: [PATCH 1/1 v2] Linux patch #1

[Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>]

[-- Attachment #1: Type: text/plain, Size: 1563 bytes --]

On Sat, Jun 30, 2018 at 09:58:49PM +0200, speck for Jiri Kosina wrote:
> On Sat, 30 Jun 2018, speck for Linus Torvalds wrote:
> 
> > But I think it's entirely unacceptable to disable SMT by default just 
> > because a user *might* run in virtualization.
> > 
> > So basically, I think the default *has* to be to keep SMT enabled (and 
> > just warn if you run virtualized loads), or to turn off SMT only for when 
> > somebody actively starts to use kvm.
> > 
> > Because the "disable SMT at boot" thing absolutely _has_ to be an explicit 
> > choice by the admin.
> > 
> > No way in hell will I accept "disable at boot" as a defaul value. Most 
> > people never run VM's at all.
> 
> Yeah, the v3 patch I just sent defaults to bare-metal mitigation only 
> ("what is default behavior" can be easily overridden by embedded 
> kernel/distro vendors if they wish to, so that they don't have to carry 
> the boot cmdline around forever) and KVM warns in case it's about to start 
> the first VM in such case.

I picked the wrong weekend to go offline and now this week is July 4th and I am
offline too.

Thomas has graciously picked up the kvm pile bundle (also attached the latest I sent)
to steam blast and I think it nicely fits in what has been decided.

That is by default we just print a warning and continue on. And the vmentry_l1d_flush
is now accepting strings (always,never, cond) and 'cond' is the default.

I think that should lay the foundation and then we can continue with the smarter
choices like disabling SMT if KVM starts creating guests or such.

[-- Attachment #2: kvm.l1tf.v5.rc2.bundle --]
[-- Type: application/octet-stream, Size: 12106 bytes --]