From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: =?utf-8?q?=3CBATV+c1f7529b87ab4cd7ee7b+5388+infradead=2Eorg+d?=
 =?utf-8?q?wmw2=40twosheds=2Esrs=2Einfradead=2Eorg=3E?=
Received: from twosheds.infradead.org ([2001:8b0:10b:1:21d:7dff:fe04:dbe2])	by
 Galois.linutronix.de with esmtps (TLS1.2:RSA_AES_256_CBC_SHA256:256)	(Exim
 4.80)	(envelope-from =?utf-8?q?=3CBATV+c1f7529b87ab4cd7ee7b+5388+infradea?=
 =?utf-8?q?d=2Eorg+dwmw2=40twosheds=2Esrs=2Einfradead=2Eorg=3E=29?=	id
 1fMAuK-0007td-FD	for speck@linutronix.de; Fri, 25 May 2018 13:29:17 +0200
Received: from [2001:8b0:10b:1::b8f]
	by twosheds.infradead.org with esmtpsa (Exim 4.90_1 #2 (Red Hat Linux))
	id 1fMAuI-00089N-Rv
	for speck@linutronix.de; Fri, 25 May 2018 11:29:14 +0000
Message-ID: <1527247753.8739.9.camel@infradead.org>
Subject: [MODERATED] Re: L1D-Fault KVM mitigation
From: David Woodhouse <dwmw2@infradead.org>
In-Reply-To: <alpine.LFD.2.21.999.1805240953520.32557@i7.lan>
References: <20180424090630.wlghmrpasn7v7wbn@suse.de>
	 <20180424093537.GC4064@hirez.programming.kicks-ass.net>
	 <1524563292.8691.38.camel@infradead.org>
	 <20180424110445.GU4043@hirez.programming.kicks-ass.net>
	 <1527068745.8186.89.camel@infradead.org>
	 <20180524094526.GE12198@hirez.programming.kicks-ass.net>
	 <alpine.LFD.2.21.999.1805240833310.32557@i7.lan>
	 <alpine.LFD.2.21.999.1805240953520.32557@i7.lan>
Date: Fri, 25 May 2018 12:29:13 +0100
Mime-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
To: speck@linutronix.de
List-ID: <speck.linutronix.de>

On Thu, 2018-05-24 at 09:57 -0700, speck for Linus Torvalds wrote:
> 
> 
> On Thu, 24 May 2018, speck for David Woodhouse wrote:
> > 
> > With decently designed hardware and SR-IOV passthrough for all I/O, and
> > posted interrupts... 
> 
> If we had decently designed hardware, we wouldn't be having this 
> discussion in the first place.

Touché.

But with decently designed hardware *around* the CPUs in question…

…actually, who am I kidding? That's bullshit too. There are plenty of
skeletons in *that* cupboard.

There may be no such thing as "decently designed hardware" but we
*have* managed to eliminate vmexits to the point where they are no
longer the first and only thing we ever have to care about. Which
really does fit into the category you mentioned:

> The only case I see making up for it is when vm entry/exit are so rare 
> (because you don't actually do much virtualization at all) that you're 
> willing to make them much much slower just to keep HT for the 95% of the 
> time when you're not doing any virtualization at all.

My point was that you can do virtualisation without taking vmexits.
Much of the last decade or so of Intel CPU design and platform design
have been about achieving exactly that.